View ATMEGA64-16AL_6636722.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

copyright ? 1999, 2000 arm limited. all rights reserved. arm ddi 0165b arm9e-s (rev 1) technical reference manual
ii copyright ? 1999, 2000 arm limited. all rights reserved. arm ddi 0165b - arm9e-s technical reference manual copyright ? 1999, 2000 arm limited. all rights reserved. release information proprietary notice arm, the arm powered logo, thumb, and strongarm are registered trademarks of arm limited. the arm logo, amba, angel, armulator, embeddedice, modelgen, multi-ice, primecell, arm7tdmi, arm7tdmi-s, arm9tdmi, arm9e-s, arm946e-s, arm966e-s, etm7, etm9, tdmi, and strong are trademarks of arm limited. all other products or services mentioned herein may be trademarks of their respective owners. neither the whole nor any part of the information contained in, or the product described in, this document may be adapted or reproduced in any material form except with the prior written permission of the copyright holder. the product described in this document is subject to continuous developments and improvements. all particulars of the product and its use contained in this document are given by arm limited in good faith. however, all warranties implied or expressed, including but not limited to implied warranties of merchantability, or fitness for purpose, are excluded. this document is intended only to assist the reader in the use of the product. arm limited shall not be liable for any loss or damage arising from the use of any information in this document, or any error or omission in such information, or any incorrect use of the product. figure c-2 on page c-4 reprinted with permission ieee std 1149.1-1990, ieee standard test access port and boundary-scan architecture copyright 2000, by ieee. the ieee disclaims any responsibility or liability resulting from the placement and use in the described manner. confidentiality status this document is open access. this document has no restriction on distribution. product status the information in this document is final (information on a developed product). web address http://www.arm.com change history date issue change 16th december 1999 a first release. 12th september 2000 b second release.
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. iii contents arm9e-s technical reference manual preface about this document .................................................................................... xvi further reading ............................................................................................ xix feedback ...................................................................................................... xx chapter 1 introduction 1.1 about the arm9e-s .................................................................................... 1-2 1.2 arm9e-s architecture ................................................................................ 1-5 1.3 arm9e-s block, core, and interface diagrams ........................................... 1-7 1.4 arm9e-s instruction set summary ........................................................... 1-10 chapter 2 programmers model 2.1 about the programmers model ................................................................... 2-2 2.2 processor operating states ......................................................................... 2-3 2.3 memory formats .......................................................................................... 2-4 2.4 instruction length ......................................................................................... 2-6 2.5 data types ................................................................................................... 2-7 2.6 operating modes ........................................................................................ 2-8 2.7 registers ..................................................................................................... 2-9 2.8 the program status registers .................................................................... 2-16 2.9 exceptions ................................................................................................ 2-20
contents iv copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b chapter 3 device reset 3.1 about device reset ...................................................................................... 3-2 3.2 reset modes .............................................................................................. 3-3 3.3 arm9e-s behavior on exit from reset ........................................................ 3-5 chapter 4 memory interface 4.1 about the memory interface ....................................................................... 4-2 4.2 instruction interface .................................................................................... 4-3 4.3 instruction interface addressing signals ..................................................... 4-4 4.4 instruction interface data timed signals ...................................................... 4-6 4.5 endian effects for instruction fetches .......................................................... 4-7 4.6 instruction interface cycle types ................................................................. 4-8 4.7 data interface ........................................................................................... 4-13 4.8 data interface addressing signals ............................................................ 4-15 4.9 data interface data timed signals ............................................................. 4-18 4.10 data interface cycle types ........................................................................ 4-24 4.11 endian effects for data transfers ............................................................... 4-30 4.12 use of clken to control bus cycles ......................................................... 4-31 chapter 5 interrupts 5.1 about interrupts .......................................................................................... 5-2 5.2 hardware interface ..................................................................................... 5-3 5.3 maximum interrupt latency ......................................................................... 5-7 5.4 minimum interrupt latency .......................................................................... 5-8 chapter 6 arm9e-s coprocessor interface 6.1 about the coprocessor interface ................................................................. 6-2 6.2 ldc/stc .................................................................................................... 6-4 6.3 mcr/mrc .................................................................................................. 6-8 6.4 mcrr/mrrc ........................................................................................... 6-10 6.5 interlocked mcr ....................................................................................... 6-12 6.6 interlocked mcrr .................................................................................... 6-13 6.7 cdp .......................................................................................................... 6-14 6.8 privileged instructions ............................................................................... 6-16 6.9 busy-waiting and interrupts ...................................................................... 6-17 6.10 coprocessor 15 mcrs ............................................................................. 6-18 6.11 connecting coprocessors ......................................................................... 6-19
contents arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. v chapter 7 debug interface and embeddedice-rt 7.1 about the debug interface ........................................................................... 7-2 7.2 debug systems ........................................................................................... 7-3 7.3 about embeddedice-rt ............................................................................ 7-6 7.4 disabling embeddedice-rt ....................................................................... 7-8 7.5 debug interface signals .............................................................................. 7-9 7.6 arm9e-s core clock domains .................................................................. 7-14 7.7 determining the core and system state ..................................................... 7-15 7.8 the debug communications channel ........................................................ 7-16 7.9 monitor mode debug ................................................................................. 7-21 chapter 8 instruction cycle times 8.1 instruction cycle count summary ................................................................. 8-3 8.2 introduction to detailed instruction cycle timings ......................................... 8-7 8.3 branch and arm branch with link ............................................................... 8-8 8.4 thumb branch with link ............................................................................... 8-9 8.5 branch and exchange ............................................................................... 8-10 8.6 thumb branch, link, and exchange ................................... 8-11 8.7 data operations ......................................................................................... 8-12 8.8 mrs .......................................................................................................... 8-14 8.9 msr operations ........................................................................................ 8-15 8.10 multiply and multiply accumulate .............................................................. 8-16 8.11 qadd, qdadd, qsub, and qdsub ....................................................... 8-20 8.12 load register ............................................................................................. 8-21 8.13 store register ............................................................................................ 8-26 8.14 load multiple registers .............................................................................. 8-27 8.15 store multiple registers ............................................................................. 8-30 8.16 load double register ................................................................................. 8-31 8.17 store double register ................................................................................. 8-32 8.18 data swap ................................................................................................. 8-33 8.19 pld ........................................................................................................... 8-35 8.20 software interrupt, undefined instruction, and exception entry ................. 8-36 8.21 coprocessor data processing operation ................................................... 8-37 8.22 load coprocessor register (from memory) ................................................ 8-38 8.23 store coprocessor register (to memory) .................................................... 8-40 8.24 coprocessor register transfer (to arm) .................................................... 8-42 8.25 coprocessor register transfer (from arm) ................................................ 8-43 8.26 double coprocessor register transfer (to arm) ......................................... 8-44 8.27 double coprocessor register transfer (from arm) .................................... 8-45 8.28 coprocessor absent .................................................................................. 8-46 8.29 unexecuted instructions ............................................................................ 8-47 chapter 9 ac parameters 9.1 timing diagrams ......................................................................................... 9-2 9.2 ac timing parameter definitions .................................................................. 9-8
contents vi copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b appendix a signal descriptions a.1 clock interface signals ................................................................................ a-2 a.2 instruction memory interface signals .......................................................... a-3 a.3 data memory interface signals ................................................................... a-4 a.4 miscellaneous signals ................................................................................. a-6 a.5 coprocessor interface signals .................................................................... a-7 a.6 debug signals ............................................................................................. a-8 appendix b differences between the arm9e-s and the arm9tdmi b.1 interface signals ......................................................................................... b-2 b.2 atpg scan interface .................................................................................. b-5 b.3 timing parameters ...................................................................................... b-6 b.4 arm9e-s design considerations ................................................................ b-7 b.5 arm9e-s debugger considerations ........................................................... b-9 appendix c debug in depth c.1 scan chains and jtag interface ................................................................ c-2 c.2 resetting the tap controller ....................................................................... c-5 c.3 instruction register ...................................................................................... c-6 c.4 public instructions ....................................................................................... c-7 c.5 test data registers .................................................................................... c-10 c.6 arm9e-s core clock domains .................................................................. c-17 c.7 determining the core and system state .................................................... c-18 c.8 behavior of the program counter during debug ........................................ c-24 c.9 priorities and exceptions .......................................................................... c-27 c.10 embeddedice-rt logic ............................................................................ c-28 c.11 vector catching ......................................................................................... c-39 c.12 single-stepping ......................................................................................... c-40 c.13 coupling breakpoints and watchpoints ..................................................... c-41 c.14 disabling embeddedice-rt .................................................................... c-44 c.15 embeddedice-rt timing .......................................................................... c-45
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. vii list of tables arm9e-s technical reference manual table 1-1 key to tables ............................................................................... 1-10 table 1-2 arm instruction set summary ..................................................... 1-12 table 1-3 addressing mode 2 ..................................................................... 1-16 table 1-4 addressing mode 2 (privileged) .................................................. 1-17 table 1-5 addressing mode 3 ..................................................................... 1-18 table 1-6 addressing mode 4 (load) ........................................................... 1-18 table 1-7 addressing mode 4 (store) .......................................................... 1-18 table 1-8 addressing mode 5 (load) ........................................................... 1-19 table 1-9 oprnd2 ........................................................................................ 1-19 table 1-10 fields .......................................................................................... 1-20 table 1-11 condition fields ........................................................................... 1-20 table 1-12 thumb instruction set summary .................................................. 1-21 table 2-1 register mode identifiers ............................................................ 2-10 table 2-2 psr mode bit values .................................................................. 2-18 table 2-3 exception entry and exit .............................................................. 2-20 table 2-4 configuration of exception vector address locations .................. 2-26 table 2-5 exception vectors ........................................................................ 2-26 table 3-1 reset modes ................................................................................. 3-3 table 4-1 transfer widths ............................................................................. 4-4 table 4-2 intrans encoding ....................................................................... 4-5 table 4-3 significant address bits ................................................................. 4-7 table 4-4 32-bit instruction fetches ............................................................... 4-7
viii copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b table 4-5 halfword accesses ....................................................................... 4-7 table 4-6 cycle types ................................................................................... 4-8 table 4-7 burst types ................................................................................. 4-10 table 4-8 transfer widths ........................................................................... 4-16 table 4-9 dntrans encoding ................................................................... 4-16 table 4-10 transfer size encoding ............................................................... 4-21 table 4-11 significant address bits .............................................................. 4-21 table 4-12 word accesses ........................................................................... 4-22 table 4-13 halfword accesses ..................................................................... 4-22 table 4-14 byte accesses ............................................................................ 4-22 table 4-15 cycle types ................................................................................. 4-24 table 4-16 burst types ................................................................................. 4-28 table 6-1 handshake signals ....................................................................... 6-7 table 6-2 handshake signal connections ................................................... 6-20 table 7-1 coprocessor 14 register map ..................................................... 7-16 table 8-1 key to tables ................................................................................. 8-3 table 8-2 arm instruction cycle counts ....................................................... 8-3 table 8-3 key to cycle timing tables ............................................................. 8-7 table 8-4 branch and arm branch with link cycle timings ........................... 8-8 table 8-5 thumb branch with link cycle timing ............................................. 8-9 table 8-6 branch and exchange cycle timing ............................................. 8-10 table 8-7 thumb branch, link and exchange cycle timing ......................... 8-11 table 8-8 data operation cycle timing ........................................................ 8-12 table 8-9 mrs cycle timing ........................................................................ 8-14 table 8-10 msr cycle timing ........................................................................ 8-15 table 8-11 mul and mla cycle timing ......................................................... 8-17 table 8-12 muls and mlas cycle timing .................................................... 8-17 table 8-13 smull, umull, smlal, and umlal cycle timing ................... 8-18 table 8-14 smulls, umulls, smlals, and umlals cycle timing ......... 8-18 table 8-15 smulxy, smlaxy, smulwy, and smlawy cycle timing ......... 8-19 table 8-16 smlalxy cycle timing ................................................................ 8-19 table 8-17 qadd, qdadd, qsub, and qdsub cycle timing .................... 8-20 table 8-18 load register operation cycle timing ........................................... 8-23 table 8-19 cycle timing for load operations resulting in interlocks .............. 8-24 table 8-20 example sequence ldrb, nop and add cycle timing ............. 8-24 table 8-21 example sequence ldrb and stmia cycle timing ................... 8-25 table 8-22 store register operation cycle timing .......................................... 8-26 table 8-23 ldm cycle timing ........................................................................ 8-28 table 8-24 stm cycle timing ........................................................................ 8-30 table 8-25 data swap cycle timing ............................................................... 8-33 table 8-26 pld operation cycle timing ......................................................... 8-35 table 8-27 exception entry cycle timing ....................................................... 8-36 table 8-28 coprocessor data operation cycle timing ................................... 8-37 table 8-29 load coprocessor register cycle timing ...................................... 8-38 table 8-30 store coprocessor register cycle timing ..................................... 8-40 table 8-31 mrc instruction cycle timing ...................................................... 8-42 table 8-32 mcr instruction cycle timing ...................................................... 8-43
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. ix table 8-33 mrrc instruction cycle timing .................................................... 8-44 table 8-34 mcrr instruction cycle timing .................................................... 8-45 table 8-35 coprocessor absent instruction cycle timing ............................... 8-46 table 8-36 unexecuted instruction cycle timing ............................................ 8-47 table 9-1 target ac timing parameters ........................................................ 9-8 table a-1 clock interface signals .................................................................. a-2 table a-2 instruction memory interface signals ............................................ a-3 table a-3 data memory interface signals ..................................................... a-4 table a-4 miscellaneous signals ................................................................... a-6 table a-5 coprocessor interface signals ....................................................... a-7 table a-6 debug signals ............................................................................... a-8 table b-1 arm9e-s signals and arm9tdmi hard macrocell equivalents ... b-2 table c-1 public instructions ........................................................................ c-7 table c-2 scan chain number allocation .................................................... c-12 table c-3 scan chain 1 bit order ................................................................ c-15 table c-4 arm9e-s embeddedice-rt logic register map ....................... c-28 table c-5 watchpoint control register for data comparison functions ........ c-31 table c-6 watchpoint control register for instruction comparison functions c-33 table c-7 debug control register bit functions ........................................... c-34 table c-8 interrupt signal control ............................................................... c-35 table c-9 debug status register bit functions ............................................. c-36
x copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. xi list of figures arm9e-s technical reference manual figure 1-1 five-stage pipeline ........................................................................ 1-3 figure 1-2 the instruction pipeline ................................................................. 1-4 figure 1-3 arm9e-s block diagram ............................................................... 1-7 figure 1-4 arm9e-s core diagram ................................................................ 1-8 figure 1-5 arm9e-s interface diagram ......................................................... 1-9 figure 2-1 big-endian addresses of bytes within words ................................. 2-4 figure 2-2 little-endian addresses of bytes within words .............................. 2-5 figure 2-3 register organization in arm state ............................................ 2-11 figure 2-4 register organization in thumb state ......................................... 2-13 figure 2-5 mapping of thumb state registers onto arm state registers ...... 2-14 figure 2-6 program status register ............................................................... 2-16 figure 3-1 power-on reset .............................................................................. 3-3 figure 3-2 arm9e-s behavior on exit from reset .......................................... 3-5 figure 4-1 simple memory cycle .................................................................... 4-8 figure 4-2 nonsequential instruction fetch cycle ............................................ 4-9 figure 4-3 sequential instruction fetch cycles .............................................. 4-11 figure 4-4 merged i-s cycle ......................................................................... 4-12 figure 4-5 arm9tdmi effect of dabort on following memory access ..... 4-19 figure 4-6 arm9e-s aborted data memory access ..................................... 4-20 figure 4-7 data replication ........................................................................... 4-23 figure 4-8 simple memory cycle .................................................................. 4-24 figure 4-9 nonsequential data memory cycle .............................................. 4-26 figure 4-10 back to back memory cycles ...................................................... 4-27 figure 4-11 sequential access cycles ............................................................ 4-28
xii copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure 4-12 use of clken ............................................................................ 4-31 figure 4-13 alteration of next memory request during waited bus cycle ....... 4-32 figure 5-1 retaking the fiq exception .......................................................... 5-4 figure 5-2 stopping clk for power saving .................................................... 5-5 figure 5-3 using clk and clken for best interrupt latency ......................... 5-6 figure 6-1 arm9e-s ldc/stc cycle timing ................................................. 6-4 figure 6-2 arm9e-s coprocessor clocking ................................................... 6-5 figure 6-3 arm9e-s mcr or mrc transfer timing ....................................... 6-8 figure 6-4 arm9e-s mcrr or mrrc transfer timing ................................ 6-10 figure 6-5 arm9e-s interlocked mcr ........................................................ 6-12 figure 6-6 arm9e-s interlocked mcrr ..................................................... 6-13 figure 6-7 arm9e-s late-canceled cdp .................................................... 6-14 figure 6-8 arm9e-s privileged instructions ................................................ 6-16 figure 6-9 arm9e-s busy waiting and interrupts ........................................ 6-17 figure 6-10 arm9e-s coprocessor 15 mcrs ............................................... 6-18 figure 6-11 coprocessor connections ........................................................... 6-19 figure 7-1 typical debug system ................................................................... 7-3 figure 7-2 arm9e-s block diagram .............................................................. 7-5 figure 7-3 the arm9e-s, tap controller, and embeddedice-rt ............... 7-6 figure 7-4 breakpoint timing .......................................................................... 7-9 figure 7-5 watchpoint entry with data processing instruction ..................... 7-11 figure 7-6 watchpoint entry with branch ..................................................... 7-12 figure 7-7 clock synchronization ................................................................ 7-14 figure 7-8 debug comms channel control register ...................................... 7-17 figure 7-9 coprocessor 14 monitor mode debug status register format ..... 7-18 figure 9-1 instruction memory interface timing ............................................. 9-2 figure 9-2 data memory interface timing ..................................................... 9-3 figure 9-3 clock enable timing ...................................................................... 9-3 figure 9-4 coprocessor interface timing ........................................................ 9-4 figure 9-5 exception and configuration timing .............................................. 9-4 figure 9-6 debug interface timing ................................................................. 9-5 figure 9-7 interrupt sensitivity status timing .................................................. 9-5 figure 9-8 jtag interface timing ................................................................... 9-6 figure 9-9 dbgsdout to dbgtdo relationship ......................................... 9-7 figure c-1 arm9e-s scan chain arrangements ............................................ c-2 figure c-2 test access port controller state transitions ................................. c-4 figure c-3 id code register format ............................................................... c-11 figure c-4 typical scan chain cell ............................................................... c-13 figure c-5 debug exit sequence .................................................................. c-22 figure c-6 debug state entry ....................................................................... c-23 figure c-7 arm9e-s embeddedice macrocell overview ........................... c-30 figure c-8 watchpoint control register for data comparison ........................ c-31 figure c-9 watchpoint control register for instruction comparison .............. c-32 figure c-10 debug control register format ..................................................... c-34 figure c-11 debug status register ................................................................. c-35 figure c-12 debug control and status register structure ............................... c-37 figure c-13 vector catch register .................................................................. c-38
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. xiii preface this preface introduces the arm9e-s and its reference documentation. it contains the following sections: ? about this document on page xiv ? further reading on page xvii ? feedback on page xviii.
preface xiv copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b about this document this document is the technical reference manual for the arm9e-s. intended audience this document has been written for hardware and software engineers who want to design or develop products based upon the arm9e-s family of processors. it assumes no prior knowledge of arm products. using this manual this document is organized into the following chapters: chapter 1 introduction read this chapter for an introduction to the arm9e-s, and for a summary of the arm9e-s instruction set. chapter 2 programmers model read this chapter for a description of the programmers model for the arm9e-s. chapter 3 device reset read this chapter for a description of the reset behavior of the arm9e-s. chapter 4 memory interface read this chapter for a description of the memory interface, including descriptions of the instruction and data interfaces. chapter 5 interrupts read this chapter for a description of interrupt operation. the chapter includes interrupt latency details. chapter 6 coprocessor interface read this chapter for a description of the coprocessor interface. the chapter includes timing diagrams for coprocessor operations. chapter 7 debug interface and embeddedice-rt read this chapter for an overview of the debug interface and the embeddedice-rt logic.
preface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. xv chapter 8 instruction cycle times read this chapter for a summary of instruction cycle timings and a description of interlocks. chapter 9 ac parameters read this chapter for a description of the ac timing parameters of the arm9e-s. appendix a signal descriptions read this chapter for a description of all the arm9e-s interface signals. appendix b differences read this chapter for a description of the differences between the arm9e-s and the arm9tdmi hard macrocell interface. appendix c debug in depth read this chapter for a detailed description of the debug interface. typographical conventions the following typographical conventions are used in this book: bold highlights arm processor signal names, and interface elements, such as menu names and buttons. also used for terms in descriptive lists, where appropriate. italic highlights special terminology, cross-references, and citations. typewriter denotes text that can be entered at the keyboard, such as commands, file and program names, and source code. type writer denotes a permitted abbreviation for a command or option. the underlined text may be entered instead of the full command or option name. typewriter italic denotes arguments to commands or functions, where the argument is to be replaced by a specific value. typewriter bold denotes language keywords when used outside example code.
preface xvi copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b timing diagram conventions this manual contains a number of timing diagrams. the following key explains the components used in these diagrams. any variations are clearly labeled when they occur. therefore, you must not attach any additional meaning unless specifically stated. key to timing diagram conventions shaded bus and signal areas are undefined, so the bus or signal can assume any value within the shaded area at that time. the actual level is unimportant and does not affect normal operation. clock bus stable high to low transient bus to high impedance bus change high/low to high high impedance to stable bus valid (correct) sampling point
preface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. xvii further reading this section lists publications by arm limited, and by third parties. if you would like further information on arm products, or if you have questions not answered by this document, please contact info@arm.com or visit our web site at http://www.arm.com . arm publications this document contains information that is specific to the arm9e-s. refer to the following documents for other relevant information: ? arm architecture reference manual (arm ddi 0100) ? arm9tdmi data sheet (arm ddi 0029) ? arm software development kit user guide (arm dui 0040). other publications this section lists relevant documents published by third parties. ? ieee std. 1149.1- 1990, standard test access port and boundary-scan architecture .
preface xviii copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b feedback arm limited welcomes feedback both on the arm9e-s, and on the documentation. feedback on the arm9e-s if you have any comments or suggestions about this product, please contact your supplier giving: ? the product name ? a concise explanation of your comments. feedback on the arm9e-s technical reference manual if you have any comments about this document, please send email to errata@arm.com giving: ? the document title ? the document number ? the page number(s) to which your comments refer ? a concise explanation of your comments. general suggestions for additions and improvements are also welcome.
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-1 chapter 1 - introduction this chapter introduces the arm9e-s. it contains the following sections: ? about the arm9e-s on page 1-2 ? arm9e-s architecture on page 1-5 ? arm9e-s block, core, and interface diagrams on page 1-7 ? arm9e-s instruction set summary on page 1-10.
introduction 1-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 1.1 about the arm9e-s the arm9e-s is a member of the arm family of general-purpose 32-bit microprocessors. the arm family offers high performance for very low power consumption and gate count. the arm architecture is based on reduced instruction set computer (risc) principles. the reduced instruction set and related decode mechanism are much simpler than those of complex instruction set computer (cisc) designs. this simplicity gives: ? a high instruction throughput ? an excellent real-time interrupt response ? a small, cost-effective, processor macrocell. the arm9e-s supports the armv5te architecture and features an enhanced multiplier design for improved dsp performance. the arm9e-s supports the arm debug architecture and features support for real-time debug, which allows critical exception handlers to execute while debugging the system. 1.1.1 the instruction pipeline the arm9e-s uses a pipeline to increase the speed of the flow of instructions to the processor. this allows several operations to take place simultaneously, and the processing and memory systems to operate continuously. a five-stage pipeline is used, consisting of fetch, decode, execute, memory, and writeback stages. this is shown in figure 1-1 on page 1-3.
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-3 figure 1-1 five-stage pipeline note the program counter points to the instruction being fetched rather than to the instruction being executed. during normal operation: ? one instruction is being fetched from memory ? the previous instruction is being decoded ? the instruction before that is being executed ? the instruction before that is performing data accesses (if applicable) ? the instruction before that is writing its data back to the register bank. arm thumb pc pc pc-4 pc-2 pc-8 pc-4 instruction fetched from memory decoding of registers used in instruction execute decode fetch memory writeback pc-12 pc-6 pc-16 pc-8 shift and alu operation write registers back to register bank data access to/from memory register read
introduction 1-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b typical pipeline operation is shown in figure 1-2. figure 1-2 the instruction pipeline 1.1.2 memory access the arm9e-s has a harvard architecture. this features separate address and data buses for both the 32-bit instruction interface and the 32-bit data interface. this achieves a significant decrease in cycles per instruction (cpi) by allowing instruction and data accesses to run concurrently. only load, store, coprocessor load, coprocessor store, and swap instructions can access data from memory. data can be 8-bit bytes, 16-bit halfwords or 32-bit words. words must be aligned to 4-byte boundaries. halfwords must be aligned to 2-byte boundaries. 1.1.3 forwarding, interlocking and data dependencies due to the nature of the five-stage pipeline, it is possible for a value to be required for use before it has been placed in the register bank by the actions of an earlier instruction. the arm9e-s control logic automatically detects these cases and stalls the core or forwards data as applicable to overcome these hazards. no intervention is required by software in these cases, although you can improve software performance by re-ordering instructions in certain situations. clk instr[31:0] da[31:0], dnmreq, dseq, dmore ia[31:1], inmreq, iseq wdata[31:0] rdata[31:0] instruction memory access data memory access register decode register read shift alu register write fdemw first multiply cycle second multiply cycle
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-5 1.2 arm9e-s architecture the arm9e-s processor has two instruction sets: ? the 32-bit arm instruction set used in arm state ? the 16-bit thumb instruction set used in thumb state. the arm9e-s is an implementation of the armv5te architecture. for details of both the arm and thumb instruction sets, refer to the arm architecture reference manual . for full details of the arm9e-s instruction set, contact arm at www.arm.com . 1.2.1 instruction compression a typical 32-bit architecture can manipulate 32-bit integers with single instructions, and address a large address space much more efficiently than a 16-bit architecture. when processing 32-bit data, a 16-bit architecture takes at least two instructions to perform the same task as a single 32-bit instruction. when a 16-bit architecture has only 16-bit instructions, and a 32-bit architecture has only 32-bit instructions, overall the 16-bit architecture has higher code density, and greater than half the performance of the 32-bit architecture. thumb implements a 16-bit instruction set on a 32-bit architecture, giving higher performance than on a 16-bit architecture, with higher code density than a 32-bit architecture. the arm9e-s gives you the choice of running in arm state, or thumb state, or a mix of the two. this allows you to optimize both code density and performance to best suit your application requirements. 1.2.2 the thumb instruction set the thumb instruction set is a subset of the most commonly used 32-bit arm instructions. thumb instructions are each 16 bits long, and have a corresponding 32-bit arm instruction that has the same effect on the processor model. thumb instructions operate with the standard arm register configuration, allowing excellent interoperability between arm and thumb states. thumb has all the advantages of a 32-bit core: ? 32-bit address space ? 32-bit registers ? 32-bit shifter and arithmetic logic unit (alu) ? 32-bit memory transfer.
introduction 1-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b thumb therefore offers a long branch range, powerful arithmetic operations, and a large address space. thumb code is typically 65% of the size of the arm code, and provides 160% of the performance of arm code when running on a processor connected to a 16-bit memory system. thumb, therefore, makes the arm9e-s ideally suited to embedded applications with restricted memory bandwidth, where code density is important. the availability of both 16-bit thumb and 32-bit arm instruction sets, gives designers the flexibility to emphasize performance or code size on a subroutine level, according to the requirements of their applications. for example, critical loops for applications such as fast interrupts and dsp algorithms can be coded using the full arm instruction set, and linked with thumb code.
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-7 1.3 arm9e-s block, core, and interface diagrams the arm9e-s architecture, core, and interface diagrams are shown in the following figures: ?the arm9e-s block diagram is shown in figure 1-3 ?the arm9e-s core diagram is shown in figure 1-4 on page 1-8 ?the arm9e-s interface diagram is shown in figure 1-5 on page 1-9. figure 1-3 arm9e-s block diagram refer to chapter 7 debug interface and embeddedice-rt for a description of the embeddedice-rt logic. arm9e-s embeddedice-rt logic arm9e-s core arm9e-s tap controller scan chain 1 scan chain 2 coprocessor interface signals dbgrng[1:0] dbgext[1:0] dlock, dnrw, dmas[1:0] dntrans, dnmreq, dseq da[31:0] wdata[31:0] rdata[31:0] dbgtcken dbgtms dbgntrst dbgtdi dbgtdo inmreq, iseq, itbit, intrans ia[31:0] instr[31:0]
introduction 1-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure 1-4 arm9e-s core diagram alu sat(x2) shifter byte/ word repl. multiplier register bank plus program counter psr instruction pipeline instruction decode and data path control logic instr[31:0] idscan ia[31:1] iascan ddscan dascan da[31:0] byte rotate/ sign extend exception vectors iareg amux bmux cmux din[31:0] c[31:0] b[31:0] a[31:0] imm shift bdata[..] adata[..] psrrd[31:0] acc sat clz dinc dareg dinfwd[31:0] wdata[31:0] rdata[31:0] resultme[31:0] aluoutex[31:0] mulresultme[31:0] incrementer
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-9 figure 1-5 arm9e-s interface diagram data memory interface debug embeddedice and scan interface coprocessor interface interrupts clock arm9e-s chse[1:0] chsd[1:0] latecancel pass dntrans[1:0] dmas[1:0] dnrw dabort rdata[31:0] wdata[31:0] da[31:0] dbgtdo dbgntrst dbgtdi dbgtms dbgtcken dmore dseq dnmreq dnm[4:0] dlock dbgntdoen dbgscreg[4:0] dbgsdin dbgsdout dbgtapsm[3:0] dbgir[3:0] tapid[31:0] dbgcommtx dbgcommrx dbgrng[1:0] dbgen dbgext[1:0] dbgack edbgrq cfgbigend nreset nfiq nirq clken clk coreclkenin coreclkenout cfgdisltbit cfghivecs ia[31:1] instr[31:0] iabort inmreq iseq itbit intrans inm[4:0] dbgdewpt dbgiebkpt dbgrqi dbginstrexec dbginstrvalid instruction memory interface miscellaneous configuration
introduction 1-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 1.4 arm9e-s instruction set summary this section provides a summary of the arm and thumb instruction sets: ? arm instruction set summary on page 1-12 ? thumb instruction set summary on page 1-21. a key to the instruction set tables is given in table 1-1. the arm9e-s is an implementation of the armv5te architecture. for a description of both instruction sets, refer to the arm architecture reference manual . contact arm for complete descriptions of both instruction sets. table 1-1 key to tables symbol description {cond} see table 1-11 on page 1-20. see table 1-9 on page 1-19. {field} see table 1-10 on page 1-20. s sets condition codes (optional). b byte operation (optional). h halfword operation (optional). tforces dntrans to be active (0). cannot be used with pre-indexed addresses. see table 1-3 on page 1-16. see table 1-4 on page 1-17. see table 1-5 on page 1-18. see table 1-6 on page 1-18. see table 1-7 on page 1-18. see table 1-8 on page 1-19. #32bit_imm a 32-bit constant, formed by right-rotating an 8-bit value by an even number of bits.
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-11 a comma-separated list of registers, enclosed in braces ({ and }). x selects high or low 16 bits of register rm. t selects the high 16 bits. (t = top) b selects the low 16 bits. (b = bottom). y selects high or low 16 bits of register rs. t selects the high 16 bits. (t = top) b selects the low 16 bits. (b = bottom). table 1-1 key to tables (continued) symbol description
introduction 1-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 1.4.1 arm instruction set summary the arm instruction set summary is given in table 1-2. table 1-2 arm instruction set summary operation assembler move move mov{cond}{s} rd, move not mvn{cond}{s} rd, move spsr to register mrs{cond} rd, spsr move cpsr to register mrs{cond} rd, cpsr move register to spsr msr{cond} spsr{field}, rm move register to cpsr msr{cond} cpsr{field}, rm move immediate to spsr flags msr{cond} spsr_flg, #32bit_imm move immediate to cpsr flags msr{cond} cpsr_flg, #32bit_imm arithmetic add add{cond}{s} rd, rn, add with carry adc{cond}{s} rd, rn, subtract sub{cond}{s} rd, rn, subtract with carry sbc{cond}{s} rd, rn, reverse subtract rsb{cond}{s} rd, rn, reverse subtract with carry rsc{cond}{s} rd, rn, multiply mul{cond}{s} rd, rm, rs multiply accumulate mla{cond}{s} rd, rm, rs, rn multiply unsigned long umull{cond}{s} rdlo, rdhi, rm, rs multiply unsigned accumulate long umlal{cond}{s} rdlo, rdhi, rm, rs multiply signed long smull{cond}{s} rdlo, rdhi, rm, rs multiply signed accumulate long smlal{cond}{s} rdlo, rdhi, rm, rs compare cmp{cond} rd, compare negative cmn{cond} rd, saturating add qadd{cond} rd, rn, rs
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-13 saturating add with double qdadd{cond} rd, rn, rs saturating subtract qsub{cond} rd, rn, rs saturating subtract with double qdsub{cond} rd, rn, rs multiply 16x16 smulxy{cond} rd, rm, rs multiply accumulate 16x16+32 smulaxy{cond} rd, rm, rs, rn multiply 32x16 smulwx{cond} rd, rm, rs multiply accumulate 32x16+32 smlawx{cond} rd, rm, rs, rn multiply signed accumulate long 16x16+64 smlalx{cond} rdlo, rdhi, rm, rs count leading zeros clz{cond} rd, rm logical test tst{cond} rn, test equivalence teq{cond} rn, and and{cond}{s} rd, rn, xor eor{cond}{s} rd, rn, or orr{cond}{s} rd, rn, bit clear bic{cond}{s} rd, rn, branch branch b{cond} label branch with link bl{cond} label branch and exchange bx{cond} rn branch, link and exchange blx{cond} label branch, link and exchange blx{cond} rn load word ldr{cond} rd, word with user mode privilege ldr{cond}t rd, byte ldr{cond}b rd, byte with user mode privilege ldr{cond}bt rd, table 1-2 arm instruction set summary (continued) operation assembler
introduction 1-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b byte signed ldr{cond}sb rd, halfword ldr{cond}h rd, halfword signed ldr{cond}sh rd, multiple block data operations stack operations ldm{cond} rd{!}, increment before ldm{cond}ib rd{!}, {^} increment after ldm{cond}ia rd{!}, {^} decrement before ldm{cond}db rd{!}, {^} decrement after ldm{cond}da rd{!}, {^} stack operations and restore cpsr ldm{cond} rd{!}, ^ user registers ldm{cond} rd{!}, ^ load double ldr{cond}d rd, store word str{cond} rd, word with user mode privilege str{cond}t rd, byte str{cond}b rd, byte with user mode privilege str{cond}bt rd, halfword str{cond}h rd, multiple block data operations stack operations stm{cond} rd{!}, increment before stm{cond}ib rd{!}, {^} increment after stm{cond}ia rd{!}, {^} decrement before stm{cond}db rd{!}, {^} decrement after stm{cond}da rd{!}, {^} user registers stm{cond} rd{!}, ^ store double str{cond}d rd, cache hint prefetch dcache line pld table 1-2 arm instruction set summary (continued) operation assembler
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-15 swap word swp{cond} rd, rm, [rn] byte swp{cond}b rd, rm, [rn] coprocessors data operations cdp{cond} p, , crd, crn, crm, move to arm reg from coproc mrc{cond} p, , rd, crn, crm, move to coproc from arm reg mcr{cond} p, , rd, crn, crm, move double to arm reg from coproc mrrc{cond} p, , rd, rn, crm move double to coproc from arm reg mcrr{cond} p, , rd, rn, crm load ldc{cond} p, crd, store stc{cond} p, crd, software interrupt swi{cond} 24bit_imm software breakpoint bkpt table 1-2 arm instruction set summary (continued) operation assembler
introduction 1-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b addressing mode 2 is summarized in table 1-3. table 1-3 addressing mode 2 operation assembler immediate offset [rn, #+/-12bit_offset] register offset [rn, +/-rm] scaled register offset [rn, +/-rm, lsl #5bit_shift_imm] [rn, +/-rm, lsr #5bit_shift_imm] [rn, +/-rm, asr #5bit_shift_imm] [rn, +/-rm, ror #5bit_shift_imm] [rn, +/-rm, rrx] pre-indexed offset - immediate [rn, #+/-12bit_offset]! register [rn, +/-rm]! scaled register [rn, +/-rm, lsl #5bit_shift_imm]! [rn, +/-rm, lsr #5bit_shift_imm]! [rn, +/-rm, asr #5bit_shift_imm]! [rn, +/-rm, ror #5bit_shift_imm]! [rn, +/-rm, rrx]! post-indexed offset - immediate [rn], #+/-12bit_offset register [rn], +/-rm scaled register [rn], +/-rm, lsl #5bit_shift_imm [rn], +/-rm, lsr #5bit_shift_imm [rn], +/-rm, asr #5bit_shift_imm [rn], +/-rm, ror #5bit_shift_imm [rn], +/-rm, rrx
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-17 addressing mode 2 (privileged) is summarized in table 1-4. table 1-4 addressing mode 2 (privileged) operation assembler immediate offset [rn, #+/-12bit_offset] register offset [rn, +/-rm] scaled register offset [rn, +/-rm, lsl #5bit_shift_imm] [rn, +/-rm, lsr #5bit_shift_imm] [rn, +/-rm, asr #5bit_shift_imm] [rn, +/-rm, ror #5bit_shift_imm] [rn, +/-rm, rrx] post-indexed offset - immediate [rn], #+/-12bit_offset register [rn], +/-rm scaled register [rn], +/-rm, lsl #5bit_shift_imm [rn], +/-rm, lsr #5bit_shift_imm [rn], +/-rm, asr #5bit_shift_imm [rn], +/-rm, ror #5bit_shift_imm [rn], +/-rm, rrx
introduction 1-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b addressing mode 3 is summarized in table 1-5. addressing mode 4 (load) is summarized in table 1-6. addressing mode 4 (store) is summarized in table 1-7. table 1-5 addressing mode 3 operation assembler immediate offset [rn, #+/-8bit_offset] pre-indexed [rn, #+/-8bit_offset]! post-indexed [rn], #+/-8bit_offset register offset [rn, +/-rm] pre-indexed [rn, +/-rm]! post-indexed [rn], +/-rm table 1-6 addressing mode 4 (load) addressing mode stack type ia increment after fd full descending ib increment before ed empty descending da decrement after fa full ascending db decrement before ea empty ascending table 1-7 addressing mode 4 (store) addressing mode stack type ia increment after ea empty ascending ib increment before fa full ascending da decrement after ed empty descending db decrement before fd full descending
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-19 addressing mode 5 (load) is summarized in table 1-8. oprnd2 is summarized in table 1-9. table 1-8 addressing mode 5 (load) operation assembler immediate offset [rn, #+/-(8bit_offset*4)] pre-indexed [rn, #+/-(8bit_offset*4)]! post-indexed [rn], #+/-(8bit_offset*4) table 1-9 oprnd2 operation assembler immediate value #32bit_imm logical shift left rm lsl #5bit_imm logical shift right rm lsr #5bit_imm arithmetic shift right rm asr #5bit_imm rotate right rm ror #5bit_imm register rm logical shift left rm lsl rs logical shift right rm lsr rs arithmetic shift right rm asr rs rotate right rm ror rs rotate right extended rm rrx
introduction 1-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b fields are summarized in table 1-10. condition fields are summarized in table 1-11. table 1-10 fields suffix sets _c control field mask bit (bit 0) _x extension field mask bit (bit 1) _s status field mask bit (bit 2) _f flags field mask bit (bit 3) table 1-11 condition fields suffix description eq equal ne not equal hs/cs unsigned higher or same lo/cc unsigned lower mi negative pl positive or zero vs overflow vc no overflow hi unsigned higher ls unsigned lower or same ge greater or equal lt less than gt greater than le less than or equal al always
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-21 1.4.2 thumb instruction set summary the thumb instruction set summary is given in table 1-12. table 1-12 thumb instruction set summary operation assembler move immediate mov rd, #8bit_imm high to low mov rd, hs low to high mov hd, rs high to high mov hd, hs arithmetic add add rd, rs, #3bit_imm add low and low add rd, rs, rn add high to low add rd, hs add low to high add hd, rs add high to high add hd, hs add immediate add rd, #8bit_imm add value to sp add sp, #7bit_imm add sp, #-7bit_imm add with carry adc rd, rs subtract sub rd, rs, rn sub rd, rs, #3bit_imm subtract immediate sub rd, #8bit_imm subtract with carry sbc rd, rs negate neg rd, rs multiply mul rd, rs compare low and low cmp rd, rs compare low and high cmp rd, hs compare high and low cmp hd, rs compare high and high cmp hd, hs compare negative cmn rd, rs
introduction 1-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b compare immediate cmp rd, #8bit_imm logical and and rd, rs xor eor rd, rs or orr rd, rs bit clear bic rd, rs move not mvn rd, rs test bits tst rd, rs shift/rotate logical shift left lsl rd, rs, #5bit_shift_imm lsl rd, rs logical shift right lsr rd, rs, #5bit_shift_imm lsr rd, rs arithmetic shift right asr rd, rs, #5bit_shift_imm asr rd, rs rotate right ror rd, rs branch conditional - if z set beq label if z clear bne label if c set bcs label if c clear bcc label if n set bmi label if n clear bpl label if v set bvs label if v clear bvc label if c set and z clear bhi label if c clear or z set bls label if n set and v set, or if n clear and v clear bge label table 1-12 thumb instruction set summary (continued) operation assembler
introduction arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 1-23 if n set and v clear, or if n clear and v set blt label if z clear, and n and v set, or if z clear, and n and v clear bgt label if z set, or n set and v clear, or n clear and v set ble label unconditional b label long branch with link bl label long branch, link and exchange instruction blx label branch and exchange to address held in low reg bx rs to address held in high reg bx hs branch, link and exchange to address held in low reg blx rs to address held in high reg blx hs load with immediate offset - word ldr rd, [rb, #7bit_offset] halfword ldrh rd, [rb, #6bit_offset] byte ldrb rd, [rb, #5bit_offset] with register offset - word ldr rd, [rb, ro] halfword ldrh rd, [rb, ro] halfword signed ldrsh rd, [rb, ro] byte ldrb rd, [rb, ro] byte signed ldrsb rd, [rb, ro] pc-relative ldr rd, [pc, #10bit_offset] sp-relative ldr rd, [sp, #10bit_offset] table 1-12 thumb instruction set summary (continued) operation assembler
introduction 1-24 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b address - using pc add rd, pc, #10bit_offset using sp add rd, sp, #10bit_offset multiple ldmia rb!, store with immediate offset - word str rd, [rb, #7bit_offset] halfword strh rd, [rb, #6bit_offset] byte strb rd, [rb, #5bit_offset] with register offset - word str rd, [rb, ro] halfword strh rd, [rb, ro] byte strb rd, [rb, ro] sp-relative str rd, [sp, #10bit_offset] multiple stmia rb!, push/pop push registers onto stack push push lr and registers onto stack push pop registers from stack pop pop registers and pc from stack pop software interrupt swi 8bit_imm software breakpoint bkpt table 1-12 thumb instruction set summary (continued) operation assembler
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-1 chapter 2 - programmers model this chapter describes the arm9e-s programmers model. it contains the following sections: ? about the programmers model on page 2-2 ? processor operating states on page 2-3 ? memory formats on page 2-4 ? instruction length on page 2-6 ? data types on page 2-7 ? operating modes on page 2-8 ? registers on page 2-9 ? the program status registers on page 2-16 ? exceptions on page 2-20.
programmers model 2-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.1 about the programmers model the arm9e-s processor core implements armv5te architecture. this includes the 32-bit arm instruction set and the 16-bit thumb instruction set. for details of both the arm and thumb instruction sets, refer to the arm architecture reference manual . the arm9e-s programmers model is described in: ? processor operating states on page 2-3 ? memory formats on page 2-4 ? instruction length on page 2-6 ? data types on page 2-7 ? operating modes on page 2-8 ? registers on page 2-9 ? the program status registers on page 2-16 ? exceptions on page 2-20.
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-3 2.2 processor operating states the arm9e-s has two operating states: arm state 32-bit, word-aligned arm instructions are executed in this state. thumb state 16-bit, halfword-aligned thumb instructions. in thumb state, the program counter (pc) uses bit 1 to select between alternate halfwords. note transition between arm and thumb states does not affect the processor mode or the register contents. 2.2.1 switching state you can switch the operating state of the arm9e-s core between arm state and thumb state using the bx and blx instructions, and loads to the pc. switching state is described in the arm architecture reference manual . for full details of the arm9e-s instruction set, contact arm. all exceptions are entered, handled, and exited in arm state. if an exception occurs in thumb state, the processor reverts to arm state. the transition back to thumb state occurs automatically on return from the exception handler. 2.2.2 interworking arm and thumb state the arm9e-s allows you to mix arm and thumb code as you wish. for details see chapter 7 interworking arm and thumb in the software development kit user guide .
programmers model 2-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.3 memory formats the arm9e-s views memory as a linear collection of bytes numbered in ascending order from zero. bytes 0 to 3 hold the first stored word, and bytes 4 to 7 hold the second stored word, for example. the arm9e-s can treat words in memory as being stored in either: ? big-endian format ? little-endian format . 2.3.1 big-endian format in big-endian format, the arm9e-s stores the most significant byte of a word at the lowest-numbered byte, and the least significant byte at the highest-numbered byte. therefore, byte 0 of the memory system connects to data lines 31 to 24. this is shown in figure 2-1. figure 2-1 big-endian addresses of bytes within words 2.3.2 little-endian format in little-endian format, the lowest-numbered byte in a word is the least-significant byte of the word and the highest-numbered byte is the most significant. therefore, byte 0 of the memory system connects to data lines 7 to 0. this is shown in figure 2-2 on page 2-5. 4 0 8 5 1 9 7 3 11 6 2 10 31 24 23 16 15 8 7 word address 0 4 0 8 higher address lower address ? most significant byte is at lowest address ? word is addressed by byte address of most significant byte bit
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-5 figure 2-2 little-endian addresses of bytes within words 7 3 11 6 2 10 4 0 8 5 1 9 31 24 23 16 15 8 7 word address 0 4 0 8 higher address lower address ? least significant byte is at lowest address ? word is addressed by byte address of least significant byte bit
programmers model 2-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.4 instruction length instructions are either: ? 32 bits long (in arm state) ? 16 bits long (in thumb state).
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-7 2.5 data types the arm9e-s supports the following data types: ? word (32-bit) ? halfword (16-bit) ? byte (8-bit). you must align these as follows: ? word quantities must be aligned to four-byte boundaries ? halfword quantities must be aligned to two-byte boundaries ? byte quantities can be placed on any byte boundary.
programmers model 2-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.6 operating modes the arm9e-s has seven modes of operation: ? user mode is the usual arm program execution state, and is used for executing most application programs. ? fast interrupt (fiq) mode is used for handling fast interrupts. ? interrupt (irq) mode is used for general-purpose interrupt handling. ? supervisor mode is a protected mode for the operating system. ? abort mode is entered after a data or instruction prefetch abort. ? system mode is a privileged user mode for the operating system. ? undefined mode is entered when an undefined instruction exception occurs. modes other than user mode are collectively known as privileged modes. privileged modes are used to service interrupts or exceptions, or to access protected resources.
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-9 2.7 registers the arm9e-s has a total of 37 registers: ? 31 general-purpose 32-bit registers ? 6 32-bit status registers. these registers are not all accessible at the same time. the processor state and operating mode determine which registers are available to the programmer. 2.7.1 the arm state register set in arm state, 16 general registers and one or two status registers are accessible at any one time. in privileged modes, mode-specific banked registers become available. figure 2-3 on page 2-11 shows which registers are available in each mode. the arm state register set contains 16 directly-accessible registers, r0 to r15. a further register, the current program status register (cpsr), contains condition code flags and the current mode bits. registers r0 to r13 are general-purpose registers used to hold either data or address values. registers r14, r15, and the cpsr have the following special functions: link register register r14 is used as the subroutine link register (lr). register r14 receives a copy of r15 when a branch with link ( bl or blx ) instruction is executed. you can treat r14 as a general-purpose register at all other times. the corresponding banked registers r14_svc, r14_irq, r14_fiq, r14_abt and r14_und are similarly used to hold the return values of r15 when interrupts and exceptions arise, or when bl or blx instructions are executed within interrupt or exception routines. program counter register r15 holds the pc. in arm state, bits [1:0] of r15 are zero. bits [31:2] contain the pc. in thumb state, bit [0] is zero. bits [31:1] contain the pc. in privileged modes, another register, the saved program status register (spsr), is accessible. this contains the condition code flags and the mode bits saved as a result of the exception that caused entry to the current mode.
programmers model 2-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b banked registers have a mode identifier that indicates which user mode register they are mapped to. these mode identifiers are shown in table 2-1. fiq mode has seven banked registers mapped to r8Cr14 (r8_fiqCr14_fiq). as a result many fiq handlers do not need to save any registers. the supervisor, abort, irq, and undefined modes each have alternative mode-specific registers mapped to r13 and r14, allowing a private stack pointer and link register for each mode. table 2-1 register mode identifiers mode mode identifier user usr a a. the usr identifier is usually omitted from register names. it is only used in descriptions where the user or system mode register is specifically accessed from another operating mode. fast interrupt fiq interrupt irq supervisor svc abort abt system usra undefined und
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-11 figure 2-3 shows the arm state registers. figure 2-3 register organization in arm state arm state general registers and program counter r0 r1 r2 r3 r4 r5 r6 r7 r8 r9 r10 r11 r12 r13 r14 r15 (pc) system and user cpsr cpsr spsr_fiq cpsr spsr_svc cpsr spsr_abt cpsr spsr_irq cpsr spsr_und arm state program status registers indicates that the normal register used by the user or system mode has been replaced by an alternative register specific to the exception mode. r0 r1 r2 r3 r4 r5 r6 r7 r8_fiq r9_fiq r10_fiq r11_fiq r12_fiq r13_fiq r14_fiq r15 (pc) fiq r0 r1 r2 r3 r4 r5 r6 r7 r13_svc r14_svc r15 (pc) supervisor r8 r9 r10 r11 r12 r0 r1 r2 r3 r4 r5 r6 r7 r13_abt r14_abt r15 (pc) abort r8 r9 r10 r11 r12 r0 r1 r2 r3 r4 r5 r6 r7 r13_irq r14_irq r15 (pc) irq r8 r9 r10 r11 r12 r0 r1 r2 r3 r4 r5 r6 r7 r13_und r14_und r15 (pc) undefined r8 r9 r10 r11 r12
programmers model 2-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.7.2 the thumb state register set the thumb state register set is a subset of the arm state set. the programmer has direct access to: ? eight general registers, r0Cr7 (for details of high register access in thumb state see accessing high registers in thumb state on page 2-15). ?the pc ? a stack pointer, sp (arm r13) ? an lr (arm r14) ?the cpsr. there are banked sps, lrs, and spsrs for each privileged mode. this register set is shown in figure 2-4 on page 2-13.
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-13 figure 2-4 register organization in thumb state thumb state general registers and program counter system and user r0 r1 r2 r3 r4 r5 r6 r7 sp lr pc cpsr cpsr spsr_fiq cpsr spsr_svc cpsr spsr_abt cpsr spsr_irq cpsr spsr_und thumb state program status registers fiq r0 r1 r2 r3 r4 r5 r6 r7 sp_fiq lr_fiq pc supervisor r0 r1 r2 r3 r4 r5 r6 r7 sp_svc lr_svc pc abort r0 r1 r2 r3 r4 r5 r6 r7 sp_abt lr_abt pc irq r0 r1 r2 r3 r4 r5 r6 r7 sp_irq lr_irq pc undefined r0 r1 r2 r3 r4 r5 r6 r7 sp_und lr_und pc indicates that the normal register used by the user or system mode has been replaced by an alternative register specific to the exception mode.
programmers model 2-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.7.3 the relationship between arm state and thumb state registers the thumb state registers relate to the arm state registers in the following way: ? thumb state r0Cr7 and arm state r0Cr7 are identical. ? thumb state cpsr and spsrs and arm state cpsr and spsrs are identical. ? thumb state sp maps onto arm state r13. ? thumb state lr maps onto arm state r14. ? the thumb state pc maps onto the arm state pc (r15). these relationships are shown in figure 2-5. figure 2-5 mapping of thumb state registers onto arm state registers note registers r0Cr7 are known as the low registers. registers r8Cr15 are known as the high registers. r0 r1 r2 r3 r5 r6 r7 r8 r9 r10 r11 r12 stack pointer (r13) link register (r14) program counter (r15) r0 r1 r2 r3 r5 r6 r7 stack pointer (sp) link register (lr) program counter (pc) cpsr cpsr spsr spsr thumb state arm state r4 r4 high registers low registers
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-15 2.7.4 accessing high registers in thumb state in thumb state, the high registers (r8Cr15) are not part of the standard register set. with assembly language programming you have limited access to them, but can use them for fast temporary storage. you can use special variants of the mov instruction to transfer a value from a low register (in the range r0Cr7) to a high register, and from a high register to a low register. the cmp instruction allows you to compare high register values with low register values. the add instruction allows you to add high register values to low register values. for more details, refer to the arm architecture reference manual .
programmers model 2-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.8 the program status registers the arm9e-s contains a cpsr, and five spsrs for exception handlers to use. the program status registers: ? hold information about the most recently performed alu operation ? control the enabling and disabling of interrupts ? set the processor operating mode. the arrangement of bits in the status registers is shown in figure 2-6. figure 2-6 program status register note the unused bits of the status registers might be used in future arm architectures, and must not be modified by software. the unused bits of the status registers are readable, to allow the processor state to be preserved (for example, during process context switches) and writable, to allow the processor state to be restored. to maintain compatibility with future arm processors, and as good practice, you are strongly advised to use a read-modify-write strategy when changing the cpsr. 2.8.1 the condition code flags the n, z, c, and v bits are the condition code flags. they can be set by arithmetic and logical operations, and also by msr and ldm instructions. the arm9e-s tests these flags to determine whether to execute an instruction. all instructions can execute conditionally on the state of the n, z, c, and v bits in arm state. in thumb state, only the branch instruction can be executed conditionally. for more information about conditional execution, refer to the arm architecture reference manual . 28 29 30 31 m0 m1 m2 m3 m4 . f i v c z n overflow condition code flags t . . . . carry/borrow/extend zero negative/less than mode bits state bit fiq disable irq disable reserved 26 27 9876543210 control bits q sticky overflow
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-17 the q flag the sticky overflow (q) flag can be set by certain multiply and fractional arithmetic instructions: ? qadd ? qdadd ?qsub ? qdsub ? smlaxy ? smlawy the q flag is sticky in that, once set by an instruction, it remains set until explicitly cleared by an msr instruction writing to cpsr. instructions cannot execute conditionally on the status of the q flag. to determine the status of the q flag you must read the psr into a register and extract the q flag from this. for details of how the q flag is set and cleared, see individual instruction definitions in the arm architectural reference manual . 2.8.2 the control bits the bottom eight bits of a psr are known collectively as the control bits . they are the: ? interrupt disable bits ? t bit ? mode bits on page 2-18. the control bits change when an exception occurs. when the processor is operating in a privileged mode, software can manipulate these bits. interrupt disable bits the i and f bits are the interrupt disable bits: ? when the i bit is set, irq interrupts are disabled ? when the f bit is set, fiq interrupts are disabled. t bit caution never use an msr instruction to force a change to the state of the t bit in the cpsr. if you do this, the processor enters an unpredictable state.
programmers model 2-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b the t bit reflects the operating state: ? when the t bit is set, the processor is executing in thumb state ? when the t bit is clear, the processor is executing in arm state. the operating state is reflected by the itbit external signal. mode bits the m4, m3, m2, m1, and m0 bits (m[4:0]) are the mode bits. these bits determine the processor operating mode as shown in table 2-2. caution an illegal value programmed into m[4:0] causes the processor to enter an unrecoverable state. if this occurs, apply reset. not all combinations of the mode bits define a valid processor mode, so take care to use only those bit combinations shown. table 2-2 psr mode bit values m[4:0] mode visible thumb state registers visible arm state registers 10000 user r0Cr7, r8-r12 a , sp, lr, pc, cpsr r0Cr14, pc, cpsr 10001 fiq r0Cr7, r8_fiq-r12_fiq a , sp_fiq, lr_fiq pc, cpsr, spsr_fiq r0Cr7, r8_fiqCr14_fiq, pc, cpsr, spsr_fiq 10010 irq r0Cr7, r8-r12 a , sp_irq, lr_irq, pc, cpsr, spsr_irq r0Cr12, r13_irq, r14_irq, pc, cpsr, spsr_irq 10011 supervisor r0Cr7, r8-r12 a , sp_svc, lr_svc, pc, cpsr, spsr_svc r0Cr12, r13_svc, r14_svc, pc, cpsr, spsr_svc 10111 abort r0Cr7, r8-r12 a , sp_abt, lr_abt, pc, cpsr, spsr_abt r0Cr12, r13_abt, r14_abt, pc, cpsr, spsr_abt 11011 undefined r0Cr7, r8-r12 a , sp_und, lr_und, pc, cpsr, spsr_und r0Cr12, r13_und, r14_und, pc, cpsr, spsr_und 11111 system r0Cr7, r8-r12 a , sp, lr, pc, cpsr r0Cr14, pc, cpsr a. access to these registers is limited in thumb state.
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-19 2.8.3 reserved bits the remaining bits in the psrs are unused, but are reserved. when changing a psr flag or control bits, make sure that these reserved bits are not altered. you must ensure that your program does not rely on reserved bits containing specific values because future processors might use some or all of the reserved bits.
programmers model 2-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.9 exceptions exceptions arise whenever the normal flow of a program has to be halted temporarily, for example, to service an interrupt from a peripheral. before attempting to handle an exception, the arm9e-s preserves the current processor state so that the original program can resume when the handler routine has finished. if two or more exceptions arise simultaneously, the exceptions are dealt with in the fixed order given in exception priorities on page 2-27. this section provides details of the arm9e-s exception handling: ? exception entry and exit summary ? entering an exception on page 2-21 ? leaving an exception on page 2-21. 2.9.1 exception entry and exit summary table 2-3 summarizes the pc value preserved in the relevant r14 on exception entry, and the recommended instruction for exiting the exception handler. table 2-3 exception entry and exit exception or entry return instruction previous state notes arm r14_x thumb r14_x swi movs pc, r14_svc pc + 4 pc+2 where the pc is the address of the swi, undefined instruction, or instruction that had the prefetch abort. undef movs pc, r14_und pc + 4 pc+2 pa b t subs pc, r14_abt, #4 pc + 4 pc+4 fiq subs pc, r14_fiq, #4 pc + 4 pc+4 where the pc is the address of the instruction that was not executed because the fiq or irq took priority. irq subs pc, r14_irq, #4 pc + 4 pc+4 dabt subs pc, r14_abt, #8 pc + 8 pc+8 where the pc is the address of the load or store instruction that generated the data abort. reset na - - the value saved in r14_svc upon reset is unpredictable . bkpt subs pc, r14_abt, #4 pc + 4 pc+4 software breakpoint.
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-21 2.9.2 entering an exception when handling an exception the arm9e-s: 1. preserves the address of the next instruction in the appropriate lr. when the exception entry is from: ? arm state, the arm9e-s copies the address of the next instruction into the lr (current pc + 4 or pc + 8 depending on the exception). ? thumb state, the arm9e-s writes the value of the pc into the lr, offset by a value (current pc + 4 or pc + 8 depending on the exception) that causes the program to resume from the correct place on return. the exception handler does not need to determine the state when entering an exception. for example, in the case of a swi, movs pc, r14_svc always returns to the next instruction regardless of whether the swi was executed in arm or thumb state. 2. copies the cpsr into the appropriate spsr. 3. forces the cpsr mode bits to a value which depends on the exception. 4. forces the pc to fetch the next instruction from the relevant exception vector. the arm9e-s can also set the interrupt disable flags to prevent otherwise unmanageable nesting of exceptions. note exceptions are always entered, handled, and exited in arm state. when the processor is in thumb state and an exception occurs, the switch to arm state takes place automatically when the exception vector address is loaded into the pc. 2.9.3 leaving an exception when an exception has completed, the exception handler must move the lr, minus an offset to the pc. the offset varies according to the type of exception, as shown in table 2-3 on page 2-20. if the s bit is set and rd = r15, the core copies the spsr back to the cpsr and clears the interrupt disable flags that were set on entry. note the action of restoring the cpsr from the spsr automatically resets the t bit to the value it held immediately prior to the exception. the i and f bits are automatically restored to the value they held immediately prior to the exception.
programmers model 2-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.9.4 reset when the nreset signal is driven low a reset occurs, and the arm9e-s abandons the executing instruction. when nreset is driven high again the arm9e-s: 1. forces cpsr[4:0] to b10011 (supervisor mode), sets the i and f bits in the cpsr, and clears the cpsr t bit. other bits in the cpsr are indeterminate. 2. forces the pc to fetch the next instruction from the reset vector address. 3. reverts to arm state, and resumes execution. after reset, all register values except the pc and cpsr are indeterminate. refer to chapter 3 device reset for more details of the arm9e-s reset behavior. 2.9.5 fast interrupt request the fast interrupt request (fiq) exception supports fast interrupts. in arm state, fiq mode has eight private registers to reduce, or even remove the requirement for register saving (minimizing the overhead of context switching). an fiq is externally generated by taking the nfiq signal input low. the nfiq input is registered internally to the arm9e-s. it is the output of this register that is used by the arm9e-s control logic. irrespective of whether exception entry is from arm state or from thumb state, an fiq handler returns from the interrupt by executing: subs pc,r14_fiq,#4 you can disable fiq exceptions within a privileged mode by setting the cpsr f flag. when the f flag is clear, the arm9e-s checks for a low level on the output of the nfiq register at the end of each instruction. fiqs and irqs are disabled when an fiq occurs. nested interrupts are allowed but it is up to the programmer to save any corruptible registers and to re-enable fiqs and interrupts. 2.9.6 interrupt request the interrupt request (irq) exception is a normal interrupt caused by a low level on the nirq input. irq has a lower priority than fiq, and is masked on entry to an fiq sequence. you can disable irq at any time, by setting the i bit in the cpsr from a privileged mode.
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-23 irrespective of whether exception entry is from arm state or thumb state, an irq handler returns from the interrupt by executing: subs pc,r14_irq,#4 you can disable irq exceptions within a privileged mode by setting the cpsr i flag. when the i flag is clear, the arm9e-s checks for a low level on the output of the nirq register at the end of each instruction. fiqs and irqs are disabled when an irq occurs. nested interrupts are allowed but it is up to you to save any corruptible registers and to re-enable fiqs and interrupts. 2.9.7 aborts an abort indicates that the current memory access cannot be completed. an abort is signaled by one of the two external abort input pins, iabort and dabort . there are two types of abort: ? prefetch abort ? data abort on page 2-23. irqs are disabled when an abort occurs. prefetch abort this is signaled by an assertion on the iabort input pin and checked at the end of each instruction fetch. when a prefetch abort occurs, the arm9e-s marks the prefetched instruction as invalid, but does not take the exception until the instruction reaches the execute stage of the pipeline. if the instruction is not executed, for example because a branch occurs while it is in the pipeline, the abort does not take place. after dealing with the cause of the abort, the handler executes the following instruction irrespective of the processor operating state: subs pc,r14_abt,#4 this action restores both the pc and the cpsr, and retries the aborted instruction. data abort this is signaled by an assertion on the dabort input pin and checked at the end of each data access, both read and write.
programmers model 2-24 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b the arm9e-s implements the base restored data abort model , which differs from the base updated data abort model implemented by the arm7tdmi-s. the difference in the data abort model affects only a very small section of operating system code, in the data abort handler. it does not affect user code. with the base restored data abort model , when a data abort exception occurs during the execution of a memory access instruction, the base register is always restored by the processor hardware to the value it contained before the instruction was executed. this removes the need for the data abort handler to unwind any base register update, which might have been specified by the aborted instruction. this greatly simplifies the software data abort handler. the abort mechanism allows you to implement a demand-paged virtual memory system. in such a system, the processor is allowed to generate arbitrary addresses. when the data at an address is unavailable, the memory management unit (mmu) signals an abort. the abort handler must then work out the cause of the abort, make the requested data available, and retry the aborted instruction. the application program needs no knowledge of the amount of memory available to it, and its state is not affected by the abort. after dealing with the cause of the abort, the handler must execute the following return instruction irrespective of the processor operating state at the point of entry: subs pc,r14_abt,#8 this action restores both the pc and the cpsr, and retries the aborted instruction. 2.9.8 software interrupt instruction you can use the software interrupt instruction ( swi ) to enter supervisor mode, usually to request a particular supervisor function. a swi handler returns by executing the following instruction, irrespective of the processor operating state: movs pc, r14_svc this action restores the pc and cpsr, and returns to the instruction following the swi . the swi handler reads the opcode to extract the swi function number. irqs are disabled when a software interrupt occurs.
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-25 2.9.9 undefined instruction when an instruction is encountered that neither the arm9e-s, nor any coprocessor in the system can handle, the arm9e-s takes the undefined instruction trap. software can use this mechanism to extend the arm instruction set by emulating undefined coprocessor instructions. after emulating the failed instruction, the trap handler executes the following instruction, irrespective of the processor operating state: movs pc,r14_und this action restores the cpsr and returns to the next instruction after the undefined instruction. irqs are disabled when an undefined instruction trap occurs. for more information about undefined instructions, refer to the arm architecture reference manual . 2.9.10 breakpoint instruction (bkpt) a breakpoint ( bkpt ) instruction operates as though the instruction caused a prefetch abort. a breakpoint instruction does not cause the arm9e-s to take the prefetch abort exception until the instruction reaches the execute stage of the pipeline. if the instruction is not executed, for example because a branch occurs while it is in the pipeline, the breakpoint does not take place. after dealing with the breakpoint, the handler executes the following instruction irrespective of the processor operating state: subs pc,r14_abt,#4 this action restores both the pc and the cpsr, and retries the breakpointed instruction. note if the embeddedice-rt logic is configured into stopping mode, a breakpoint instruction causes the arm9e-s to enter debug state. see debug control register on page c-34.
programmers model 2-26 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2.9.11 exception vectors you can configure the location of the exception vector addresses using the input cfghivecs , as shown in table 2-4. table 2-5 shows the exception vector addresses and entry conditions for the different exception types. table 2-4 configuration of exception vector address locations value of cfghivecs exception vector base location 0 0x0000 0000 1 0xffff 0000 table 2-5 exception vectors exception offset from vector base mode on entry i bit on entry f bit on entry reset 0x00 supervisor disabled disabled undefined instruction 0x04 undefined disabled unchanged software interrupt 0x08 supervisor disabled unchanged abort (prefetch) 0x0c abort disabled unchanged abort (data) 0x10 abort disabled unchanged reserved 0x14 reserved - - irq 0x18 irq disabled unchanged fiq 0x1c fiq disabled disabled
programmers model arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 2-27 2.9.12 exception priorities when multiple exceptions arise at the same time, a fixed priority system determines the order in which they are handled: 1. reset (highest priority). 2. data abort. 3. fiq. 4. irq. 5. prefetch abort. 6. bkpt, undefined instruction, and swi (lowest priority). some exceptions cannot occur together: ? the bkpt, or undefined instruction, and swi exceptions are mutually exclusive. each corresponds to a particular (non-overlapping) decoding of the current instruction. ? when fiqs are enabled, and a data abort occurs at the same time as an fiq, the arm9e-s enters the data abort handler, and proceeds immediately to the fiq vector. a normal return from the fiq causes the data abort handler to resume execution. data aborts must have higher priority than fiqs to ensure that the transfer error does not escape detection. you must add the time for this exception entry to the worst-case fiq latency calculations in a system that uses aborts to support virtual memory. the fiq handler must not access any memory that can generate a data abort, because the initial data abort exception condition is lost.
programmers model 2-28 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 3-1 chapter 3 - device reset this chapter describes the arm9e-s reset behavior. it contains the following sections: ? about device reset on page 3-2 ? reset modes on page 3-3 ? arm9e-s behavior on exit from reset on page 3-5.
device reset 3-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 3.1 about device reset this section describes the arm9e-s reset signals and how you must use them for correct operation of the device. the arm9e-s has two reset inputs: nreset the nreset signal is the main cpu reset that initializes the majority of the arm9e-s logic. dbgntrst the dbgntrst signal is the debug logic reset that you can use to reset the arm9e-s tap controller and the embeddedice-rt unit. both nreset and dbgntrst are active low signals that asynchronously reset logic in the arm9e-s. you must take care when designing the logic to drive these reset signals.
device reset arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 3-3 3.2 reset modes two reset signals are present in the arm9e-s design to enable you to reset different parts of the design independently. a description of the reset signaling combinations and possible applications is shown in table 3-1. 3.2.1 power-on reset you must apply power-on or cold reset to the arm9e-s when power is first applied to the system. in the case of power-on reset, the leading (falling) edge of the reset signals ( nreset and dbgntrst ) does not have to be synchronous to clk . the trailing (rising) edge of the reset signals must be set up and held about the rising edge of the clock. you must do this to ensure that the entire system leaves reset in a predictable manner. this is particularly important in multi-processor systems. figure 3-1 shows the application of power-on reset. figure 3-1 power-on reset it is recommended that you assert the reset signals for at least three clk cycles to ensure correct reset behavior. adopting a three-cycle reset eases the integration of other arm parts into the system, for example, arm9tdmi based designs. table 3-1 reset modes reset mode nreset dbgntrst application power-on reset 0 0 reset at power up, full system reset. cpu reset 0 1 reset of cpu core only, watchdog reset. embeddedice-rt reset 1 0 reset of embeddedice-rt circuitry. normal 1 1 no reset. normal run mode. clk nreset dbgntrst
device reset 3-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 3.2.2 cpu reset a cpu or warm reset initializes the majority of the arm9e-s cpu, excluding the arm9e-s tap controller and the embeddedice-rt unit. cpu reset is typically used for resetting a system that has been operating for some time, for example, watchdog reset. sometimes you might not want to reset the embeddedice-rt unit when resetting the rest of the arm9e-s, for example, if embeddedice-rt has been configured to breakpoint (or capture) fetches from the reset vector. for cpu reset, both the leading and trailing edges of nreset must be set up and held about the rising edge of clk . this ensures that there are no metastability issues between the arm9e-s and the embeddedice-rt unit. 3.2.3 embeddedice-rt reset embeddedice-rt reset initializes the state of the arm9e-s tap controller and the embeddedice-rt unit. embeddedice-rt reset is typically used by the multi-ice module for hot connection of a debugger to a system. embeddedice-rt reset allows initialization of the embeddedice-rt unit without affecting the normal operation of the arm9e-s. for embeddedice-rt reset, both the leading and trailing edges of dbgntrst must be set up and held about the rising edge of clk . this ensures that there are no metastability issues between the arm9e-s and the embeddedice-rt unit. refer to clocks and synchronization on page 7-14 for more details of synchronization between the multi-ice and arm9e-s. 3.2.4 normal operation during normal operation, neither cpu reset nor embeddedice-rt reset is asserted.
device reset arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 3-5 3.3 arm9e-s behavior on exit from reset when nreset is driven low, the currently executing instruction terminates abnormally. inmreq , iseq , dnmreq , dseq , and dmore change asynchronously to indicate an internal cycle. when nreset is driven high, the arm9e-s starts requesting instructions from memory again once the nreset signal has been registered, and the first memory access starts two cycles later. the nreset signal is sampled on the rising-edge of clk . the behavior of the memory interface coming out of reset is shown in figure 3-2. figure 3-2 arm9e-s behavior on exit from reset clk inmreq ia[31:1] instr[31:0] 0x0 dnmreq dseq dmore dnrw mw de f nreset iseq da[31:0] 0x4 0x8
device reset 3-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-1 chapter 4 - memory interface this chapter describes the arm9e-s memory interface. it contains the following sections: ? about the memory interface on page 4-2 ? instruction interface on page 4-3 ? instruction interface addressing signals on page 4-4 ? instruction interface data timed signals on page 4-6 ? endian effects for instruction fetches on page 4-7 ? instruction interface cycle types on page 4-8 ? data interface on page 4-13 ? data interface addressing signals on page 4-15 ? data interface data timed signals on page 4-18 ? data interface cycle types on page 4-24 ? endian effects for data transfers on page 4-30 ? use of clken to control bus cycles on page 4-31.
memory interface 4-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.1 about the memory interface the arm9e-s has a harvard bus architecture with separate instruction and data interfaces. this allows concurrent instruction and data accesses, and greatly reduces the cycles per instruction (cpi) of the processor. for optimal performance, single-cycle memory accesses for both interfaces are required, although the core can be wait-stated for nonsequential accesses, or slower memory systems. for both instruction and data interfaces, the arm9e-s processor core uses pipelined addressing. this means that the address and control signals are generated the cycle before the data transfer takes place. all memory accesses are timed with the clock clk . for each interface there are different types of memory access: ? nonsequential ?sequential ? internal ? coprocessor transfer (for the data interface). the arm9e-s can operate in both big-endian and little-endian memory configurations and this is selected by the cfgbigend input. the endian configuration affects both interfaces, so you must take care when designing the memory interface logic to allow correct operation of the processor core. for system programming purposes, you must normally provide some mechanism for the data interface to access instruction memory. there are two main reasons for this: ? the use of in-line data for literal pools is very common. this data is fetched using the data interface but is normally contained in the instruction memory space. ? to enable debug using the jtag interface it must be possible to download code into the instruction memory. this code has to be written to memory through the data interface, because the instruction interface is read-only. in this case it is essential for the data interface to have access to the instruction memory. a typical implementation of an arm9e-s based cached processor has harvard caches and a unified memory structure beyond the caches, therefore giving the data interface access to the instruction memory space. however, for an sram-based system, you cannot use this technique, and you must use an alternative method. it is not necessary for the instruction interface to have access to the data memory area unless the processor needs to execute code from data memory.
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-3 4.2 instruction interface the arm9e-s requests instructions for execution using the instruction memory interface. a new instruction is fetched over the instruction bus whenever an instruction enters the execute stage of the pipeline. instruction fetches take place in the fetch stage of the pipeline. 4.2.1 instruction interface signals the signals in the arm9e-s instruction interface can be grouped into four categories: ? clocking and clock control signals: clk clken nreset . ? address class signals: ia[31:1] itbit intrans inm[4:0] . ? memory request signals: inmreq iseq . ? data timed signals: instr[31:0] iabort . each of these signal groups shares a common timing relationship to the bus interface cycle. all signals in the arm9e-s instruction interface are generated from, or sampled by, the rising edge of clk . you can extend bus cycles using the clken signal (see use of clken to control bus cycles on page 4-31). unless otherwise stated clken is permanently high.
memory interface 4-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.3 instruction interface addressing signals the address class signals for the instruction memory interface are: ? ia[31:1] ? itbit ? intrans on page 4-5 ? inm[4:0] on page 4-5. 4.3.1 ia[31:1] ia[31:1] is the 31-bit address bus that specifies the address for the transfer. all addresses are byte addresses, so a burst of 32-bit instruction fetches results in the address bus incrementing by four for each cycle. note the arm9e-s does not produce ia[0] as all instruction accesses are halfword-aligned (that is, ia[0] = 0). the address bus provides 4gb of linear addressing space. when a word access is signaled the memory system must ignore ia[1] . 4.3.2 itbit the itbit signal encodes the size of the instruction fetch. the arm9e-s can request word-sized instructions (when in arm state) or halfword-sized instructions (when in thumb state). this is encoded on itbit as shown in table 4-1. the size of transfer does not change during a burst of s cycles. table 4-1 transfer widths itbit transfer width 1 halfword 0word
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-5 4.3.3 intrans the intrans signal encodes information about the transfer. a memory management unit uses this signal to determine if an access is from a privileged mode. therefore, you can use this signal to implement an access permission scheme. the encoding of intrans is shown in table 4-2. 4.3.4 inm[4:0] inm[4:0] indicates the operating mode of the arm9e-s. this bus corresponds to the bottom 5 bits of the cpsr, the outputs are inverted with respect to the cpsr. table 4-2 intrans encoding intrans mode 0 user 1 privileged
memory interface 4-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.4 instruction interface data timed signals the data timed signals for the instruction memory interface are: ? instr[31:0] ? iabort . 4.4.1 instr[31:0] instr[31:0] is the read data bus, and is used by the arm9e-s to fetch opcodes. the instr[31:0] signal is sampled on the rising edge of clk at the end of the bus cycle. 4.4.2 iabort iabort indicates that an instruction fetch failed to complete successfully. iabort is sampled at the end of the bus cycle during active memory cycles (s cycles and n cycles). if iabort is asserted on an opcode fetch, the abort is tracked down the pipeline, and the prefetch abort trap is taken if the instruction is executed. iabort can be used by a memory management system to implement, for example, a basic memory protection scheme, or a demand-paged virtual memory system. for more details about aborts, see aborts on page 2-23.
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-7 4.5 endian effects for instruction fetches the arm9e-s performs 32-bit or 16-bit instruction fetches depending on whether the processor is in arm or thumb state. the processor state can be determined externally by the value of the itbit signal. when this signal is low, the processor is in arm state, and 32-bit instructions are fetched. when itbit is high, the processor is in thumb state and 16-bit instructions are fetched. the address produced by the arm9e-s is always halfword-aligned. however, the memory system must ignore bit 1of the address, depending on the size of the instruction request. the significant address bits are listed in table 4-3. when a halfword instruction fetch is performed, a 32-bit memory system can return the complete 32-bit word, and the arm9e-s extracts the valid halfword field from it. the field extracted depends on the state of the cfgbigend signal, which determines the endianness of the system (see memory formats on page 2-4). the fields extracted by the arm9e-s are shown in table 4-4. when connecting 8-bit or 16-bit memory systems to the arm9e-s, ensure that the data is presented to the correct byte lanes on the arm9e-s as shown in table 4-5. table 4-3 significant address bits itbit width significant address bits 1 halfword ia[31:1] 0word ia[31:2] table 4-4 32-bit instruction fetches itbit ia[1] little-endian cfgbigend = 0 big-endian cfgbigend = 1 0 x instr[31:0] instr[31:0] table 4-5 halfword accesses itbit ia[1] little-endian cfgbigend = 0 big-endian cfgbigend = 1 1 0 instr[15:0] instr[31:16] 1 1 instr[31:16] instr[15:0]
memory interface 4-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.6 instruction interface cycle types the arm9e-s instruction interface is pipelined. the address class signals and the memory request signals are broadcast in the bus cycle ahead of the bus cycle to which they refer. this gives the maximum time for a memory cycle to decode the address, and respond to the access request. a single memory cycle is shown in figure 4-1. figure 4-1 simple memory cycle the arm9e-s instruction interface can perform three different types of memory cycle. these are indicated by the state of the inmreq and iseq signals. memory cycle types are encoded on the inmreq and iseq signals as shown in table 4-6. a memory controller for the arm9e-s must commit to an instruction memory access only on an n cycle or an s cycle. clk address class signals inmreq, iseq instr[31:0] address cycle type instruction data bus cycle table 4-6 cycle types inmreq iseq cycle type description 0 0 n cycle nonsequential cycle 0 1 s cycle sequential cycle 1 0 i cycle internal cycle 1 1 - reserved
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-9 the arm9e-s instruction interface has three types of memory cycle: nonsequential cycle during this the arm9e-s core requests a transfer to or from an address that is unrelated to the address used in the preceding cycle. sequential cycle during this the arm9e-s core requests a transfer to or from an address that is either one word, or one halfword greater than the address used in the preceding cycle. internal cycle during this the arm9e-s core does not require a transfer because it is performing an internal function, and no useful prefetching can be performed at the same time. 4.6.1 instruction interface, nonsequential cycles a nonsequential instruction fetch is the simplest form of an arm9e-s instruction interface cycle, and occurs when the arm9e-s requests a transfer to or from an address that is unrelated to the address used in the preceding cycle. the memory controller must initiate a memory access to satisfy this request. the address class signals and the inmreq, iseq = n cycle signals are broadcast on the instruction interface bus. at the end of the next bus cycle the instruction is transferred to the cpu from memory. this is shown in figure 4-2. figure 4-2 nonsequential instruction fetch cycle clk address class signals inmreq, iseq instr[31:0] address n cycle instruction data n cycle
memory interface 4-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.6.2 instruction interface, sequential cycles sequential instruction fetches are used to perform burst transfers on the bus. this information can be used to optimize the design of a memory controller interfacing to a burst memory device, such as a dram. during a sequential cycle, the arm9e-s requests a memory location that is part of a sequential burst. if this is the first cycle in the burst, the address might be the same as the previous internal cycle. otherwise the address is incremented from the previous instruction fetch that was performed: ? for a burst of word accesses, the address is incremented by 4 bytes ? for a burst of halfword access, the address is incremented by 2 bytes. the types of bursts are shown in table 4-7. all accesses in a burst are of the same width, direction, and protection type. for more details, see instruction interface addressing signals on page 4-4. bursts of byte accesses are not possible with the instruction memory interface. a burst always starts with an n cycle, or a merged i-s cycle (see instruction interface, merged i-s cycles on page 4-11), and continues with s cycles. a burst comprises transfers of the same type or size. the ia[31:1] signal increments during the burst. the other address class signals are unaffected by a burst. an example of a burst access is shown in figure 4-3 on page 4-11. table 4-7 burst types burst type address increment cause word read 4 bytes arm code fetches halfword read 2 bytes thumb code fetches
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-11 figure 4-3 sequential instruction fetch cycles 4.6.3 instruction interface, internal cycles during an internal cycle, the arm9e-s does not require an instruction fetch, because an internal function is being performed, and no useful prefetching can be performed at the same time. where possible the arm9e-s broadcasts the address for the next access, so that decode can start, but the memory controller must not commit to a memory access. this is described further in instruction interface, merged i-s cycles . 4.6.4 instruction interface, merged i-s cycles where possible, the arm9e-s performs an optimization on the bus to allow extra time for memory decode. when this happens, the address of the next memory cycle is broadcast during an internal cycle on this bus. this allows the memory controller to decode the address, but it must not initiate a memory access during this cycle. in a merged i-s cycle, the next cycle is a sequential cycle to the same memory location. this commits to the access, and the memory controller must initiate the memory access. this is shown in figure 4-4 on page 4-12. clk address class signals inmreq, iseq instr[31:0] address n cycle instruction data 1 n cycle address + 4 s cycle instruction data 2 s cycle
memory interface 4-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure 4-4 merged i-s cycle there is an exception to the merged i-s behavior in the case of a coprocessor 15 mcr . in this case the ia bus is used to transmit data to cp15 (see coprocessor 15 mcrs on page 6-18). note when designing a memory controller, make sure that the design also works when an i cycle is followed by an n cycle to a different address. this sequence might occur during exceptions, or during writes to the program counter. it is essential that the memory controller does not commit to the memory cycle during an i cycle. clk address class signals inmreq, iseq instr[31:0] address i cycle instruction data 1 i cycle address + 2 s cycle instruction data 2 merged s cycle s cycle s cycle
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-13 4.7 data interface the arm9e-s requests data using the data memory interface. data transfers take place in the memory stage of the pipeline. the operation of the data interface is very similar to the instruction interface. 4.7.1 data interface signals the signals in the arm9e-s data bus interface can be grouped into four categories: ? clocking and clock control signals: clk clken nreset . ? address class signals: da[31:0] dntrans dnrw dnm[4:0] dmas[1:0] dlock . ? memory request signals: dnmreq dseq dmore . ? data timed signals: wdata[31:0] rdata[31:0] dabort . note all memory accesses are conditioned by the state of the memory request signals. you must not initiate a memory access unless the memory request signals indicate that one is required. see data interface cycle types on page 4-24 for more details.
memory interface 4-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b each of these signal groups shares a common timing relationship to the bus interface cycle. all signals in the arm9e-s data interface are generated from, or sampled by the rising edge of clk . you can extend bus cycles using the clken signal (see use of clken to control bus cycles on page 4-31). unless otherwise stated clken is permanently high.
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-15 4.8 data interface addressing signals the address class signals are: ? da[31:0] ? dnrw ? dmas[1:0] on page 4-16 ? dntrans on page 4-16 ? dlock on page 4-17 ? dnm[4:0] on page 4-17. 4.8.1 da[31:0] da[31:0] is the 32-bit address bus that specifies the address for the transfer. all addresses are byte addresses, so a burst of word accesses results in the address bus incrementing by 4 for each cycle. the address bus provides 4gb of linear addressing space. when a word access is signaled the memory system must ignore the bottom two bits, da[1:0] , and when a halfword access is signaled the memory system must ignore the bottom bit, da[0] . 4.8.2 dnrw dnrw specifies the direction of the transfer. dnrw indicates an arm9e-s write cycle when high, and an arm9e-s read cycle when low. a burst of s cycles is always either a read burst, or a write burst, because the direction cannot be changed in the middle of a burst. note you must not initiate writes to memory purely on the basis of dnrw . you must use the status of the data interface request signals to condition writes to memory. see data interface cycle types on page 4-24 for more details.
memory interface 4-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.8.3 dmas[1:0] the dmas[1:0] bus encodes the size of the transfer. the arm9e-s can transfer word, halfword, and byte quantities. this is encoded on dmas[1:0] as shown in table 4-8. the size of transfer does not change during a burst of s cycles. bursts of halfword or byte accesses are not possible on the arm9e-s data interface. note a writable memory system for the arm9e-s must have individual byte write enables. both the c compiler and the arm debug tool chain (for example, multi-ice) assume that arbitrary bytes in the memory can be written. if individual byte write capability is not provided, you might not be able to use these tools. 4.8.4 dntrans the dntrans bus encodes information about the transfer. a memory management unit uses this signal to determine if an access is from a privileged mode. therefore, you can use this signal to implement an access permission scheme. the encoding of dntrans is shown in table 4-9. table 4-8 transfer widths dmas[1:0] transfer width 00 byte 01 halfword 10 word 11 reserved table 4-9 dntrans encoding dntrans mode 0user 1 privileged
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-17 4.8.5 dlock dlock indicates to an arbiter that an atomic operation is being performed on the bus. dlock is normally low, but is set high to indicate that a swp or swpb instruction is being performed. these instructions perform an atomic read/write operation, and can be used to implement semaphores. if dlock is asserted in a cycle, then this indicates that there is another access in the next cycle that must be locked to the first. in the case of a multi-master system, the arm processor must not be degranted the bus when a locked transaction is being performed. 4.8.6 dnm[4:0] dnm[4:0] indicates the operating mode of the arm9e-s. this bus corresponds to the bottom five bits of the cpsr, unless a forced user mode access is being performed, in which case dnm[4:0] indicates user mode. these bits are inverted with respect to the cpsr.
memory interface 4-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.9 data interface data timed signals the data timed signals are: ? wdata[31:0] ? rdata[31:0] ? dabort . 4.9.1 wdata[31:0] wdata[31:0] is the write data bus. all data written out from the arm9e-s is broadcast on this bus. data transfers from the arm9e-s to a coprocessor also use this bus during c cycles. in normal circumstances, a memory system must sample the wdata[31:0] bus on the rising edge of clk at the end of a write bus cycle. the value on wdata[31:0] is valid only during write cycles. 4.9.2 rdata[31:0] rdata[31:0] is the read data bus, and is used by the arm9e-s to fetch data. it is sampled on the rising edge of clk at the end of the bus cycle, and is also used during c cycles to transfer data from a coprocessor to the arm9e-s. 4.9.3 dabort dabort indicates that a memory transaction failed to complete successfully. dabort is sampled at the end of the bus cycle during active memory cycles (s cycles and n cycles). if dabort is asserted on a data access, it causes the arm9e-s to take the data abort trap. dabort can be used by a memory management system to implement, for example, a basic memory protection scheme, or a demand-paged virtual memory system. the arm9e-s design differs from arm9tdmi in that arm9tdmi features a combinational path from dabort to dnmreq , dseq , and dmore . this path is present so that an aborted memory access can cancel memory accesses requested by following instructions. an example of this is shown in figure 4-5 on page 4-19, where a load instruction follows an aborted store.
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-19 figure 4-5 arm9tdmi effect of dabort on following memory access this dabort to dnmreq , dseq , and dmore path has been removed from the arm9e-s design because: ? a combinational input to output path is undesirable in an asic design flow ? the path is critical in arm9tdmi. due to this modification, the memory system connected to arm9e-s is responsible for ignoring a data memory request made during the cycle of an aborted data transfer. this is necessary to prevent a following memory access from corrupting memory after an aborted access. the memory system must ignore dnmreq , dseq , and dmore in this case. clk address class signals dnrw write address write cycle (aborted) read address i cycle dnmreq dseq dmore wdata[31:0] (write) write data dabort
memory interface 4-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure 4-6 shows the arm9e-s behavior for an aborted str instruction followed by an ldm instruction. while the str instruction is canceled, a memory request is made in the first cycle of the ldm before the data abort exception is taken. figure 4-6 arm9e-s aborted data memory access for more details about aborts, see aborts on page 2-23. clk address class signals dnrw write address write cycle (aborted) read address read cycle (ignored by memory system) dnmreq dseq dmore wdata[31:0] (write) write data dabort
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-21 4.9.4 byte and halfword accesses the arm9e-s indicates the size of a transfer using the dmas[1:0] signals. these are encoded as shown in table 4-10. all writable memory in an arm9e-s based system must support the writing of individual bytes to allow the use of the c compiler and the arm debug tool chain (for example, multi-ice). the address produced by the arm9e-s is always byte-aligned. however, the memory system must ignore the insignificant bits of the address. the significant address bits are listed in table 4-11. reads when a halfword or byte read is performed, a 32-bit memory system can return the complete 32-bit word, and the arm9e-s extracts the valid halfword or byte field from it. the fields extracted depend on the state of the cfgbigend signal, which determines the endianness of the system (see memory formats on page 2-4). table 4-10 transfer size encoding dmas[1:0] transfer width 00 byte 01 halfword 10 word 11 reserved table 4-11 significant address bits dmas[1:0] width significant address bits 00 byte da[31:0] 01 halfword da[31:1] 10 word da[31:2]
memory interface 4-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b the fields extracted by the arm9e-s are shown in table 4-12. when performing a word load, the arm9e-s can rotate the data returned internally if the address used is unaligned. refer to the arm architectural reference manual for more details. when connecting 8-bit to 16-bit memory systems to the arm9e-s, you must make sure that the data is presented to the correct byte lanes on the arm9e-s as shown in table 4-13 and table 4-14. table 4-12 word accesses dmas[1:0] da[1:0] little-endian cfgbigend = 0 big-endian cfgbigend = 1 10 xx rdata[31:0] rdata[31:0] table 4-13 halfword accesses dmas[1:0] da[1:0] little-endian cfgbigend = 0 big-endian cfgbigend = 1 01 0x rdata[15:0] rdata[31:16] 01 1x rdata[31:16] rdata[15:0] table 4-14 byte accesses dmas[1:0] da[1:0] little-endian cfgbigend = 0 big-endian cfgbigend = 1 00 00 rdata[7:0] rdata[31:24] 00 01 rdata[15:8] rdata[23:16] 00 10 rdata[23:16] rdata[15:8] 00 11 rdata[31:24] rdata[7:0]
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-23 writes when the arm9e-s performs a byte or halfword write, the data being written is replicated across the bus, as illustrated in figure 4-7. the memory system can use the most convenient copy of the data. a writable memory system must be capable of performing a write to any single byte in the memory system. this capability is required by the arm c compiler and the debug tool chain. figure 4-7 data replication byte writes halfword writes arm9e-s register[7:0] a b a b a b a b a b memory interface wdata[23:16] wdata[7:0] arm9e-s register[15:0] c d wdata[31:16] wdata[15:0] a b c d a b c d a b wdata[31:24] wdata[15:8] memory interface
memory interface 4-24 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.10 data interface cycle types the arm9e-s data interface is pipelined, and so the address class signals and the memory request signals are broadcast in the bus cycle ahead of the bus cycle to which they refer. this gives the maximum time for a memory controller to decode the address, and respond to the access request. a single memory cycle is shown in figure 4-8. figure 4-8 simple memory cycle the arm9e-s data interface can perform four different types of memory cycle. these are indicated by the state of the dnmreq and dseq signals. memory cycle types are encoded on the dnmreq and dseq signals as shown in table 4-15. clk address class signals dnmreq, dseq, dmore rdata[31:0] (read) address cycle type read data bus cycle wdata[31:0] (write) write data table 4-15 cycle types dnmreq dseq cycle type description 0 0 n cycle nonsequential cycle 0 1 s cycle sequential cycle 1 0 i cycle internal cycle 1 1 c cycle coprocessor register transfer cycle
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-25 a memory controller for the arm9e-s must commit to a data memory access only on an n cycle or an s cycle. the arm9e-s data interface has four types of memory cycle: nonsequential cycle during this cycle the arm9e-s core requests a transfer to or from an address that is unrelated to the address used in the preceding cycle. sequential cycle during this cycle the arm9e-s core requests a transfer to or from an address that is one word greater than the address used in the preceding cycle. internal cycle during this cycle the arm9e-s core does not require a transfer because it is performing an internal function. coprocessor register transfer cycle during this cycle the arm9e-s core uses the data bus to communicate with a coprocessor, but does not require any action by the memory system. 4.10.1 data interface, nonsequential cycles a nonsequential cycle is the simplest form of an arm9e-s data interface cycle, and occurs when the arm9e-s requests a transfer to or from an address that is unrelated to the address used in the preceding cycle. the memory controller must initiate a memory access to satisfy this request. the address class signals and the dnmreq and dseq = n cycle are broadcast on the data bus. at the end of the next bus cycle the data is transferred between the cpu and the memory. this is shown in figure 4-9 on page 4-26.
memory interface 4-26 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure 4-9 nonsequential data memory cycle the arm9e-s can perform back to back, nonsequential memory cycles. this happens, for example, when an str instruction and an ldr instruction are executed in succession, as shown in figure 4-10 on page 4-27. clk address class signals dnmreq, dseq, dmore rdata[31:0] (read) address n cycle read data n cycle wdata[31:0] (write) write data
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-27 figure 4-10 back to back memory cycles if you are designing a memory controller for the arm9e-s, and your memory system is unable to cope with this case, use the clken signal to extend the bus cycle to allow sufficient cycles for the memory system (see use of clken to control bus cycles on page 4-31). 4.10.2 data interface, sequential cycles sequential cycles perform burst transfers on the bus. you can use this information to optimize the design of a memory controller interfacing to a burst memory device, such as a dram. during a sequential cycle, the arm9e-s requests a memory location that is part of a sequential burst. if this is the first cycle in the burst, the address can be the same as the previous internal cycle. otherwise the address is incremented from the previous cycle. for a burst of word accesses, the address is incremented by 4 bytes. bursts of halfword or byte accesses are not possible on the arm9e-s data interface. a burst always starts with an n cycle and continues with s cycles. a burst comprises transfers of the same type. the da[31:0] signal increments during the burst. the other address class signals are unaffected by a burst. clk address class signals dnmreq, dseq, dmore rdata[31:0] (read) write address n cycle read data write cycle wdata[31:0] (write) write data read address n cycle dnrw read cycle
memory interface 4-28 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b the types of bursts are shown in table 4-16. all accesses in a burst are of the same width, direction, and protection type. for more details, see instruction interface addressing signals on page 4-4. an example of a burst access is shown in figure 4-11. figure 4-11 sequential access cycles the dmore signal is active during load and store multiple instructions and only ever goes high when dnmreq is low. this signal effectively gives the same information as dseq , but a cycle ahead. this information is provided to allow external logic more time to decode sequential cycles. table 4-16 burst types burst type address increment cause word read 4 bytes ldm instruction word write 4 bytes stm instruction dmore clk address class signals dseq rdata[31:0] (read) address read data 2 n cycle wdata[31:0] (write) write data 1 address + 4 dnmreq s cycle write data 2 read data 1
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-29 4.10.3 data interface, internal cycles during an internal cycle, the arm9e-s does not require a memory access, as an internal function is being performed. 4.10.4 data interface, merged i-s cycles the arm9e-s does not perform merged i-s cycles on the data memory interface. 4.10.5 data interface, coprocessor register transfer cycles during a coprocessor register transfer cycle, the arm9e-s uses the data interface to transfer data to or from a coprocessor. a memory cycle is not required and the memory controller does not initiate a transaction. the coprocessor interface is described in chapter 6 coprocessor interface .
memory interface 4-30 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 4.11 endian effects for data transfers the arm9e-s supports 32-bit, 16-bit, and 8-bit data memory access sizes. the endian configuration of the processor, set by cfgbigend , affects only nonword transfers (16-bit and 8-bit transfers). 4.11.1 writes for data writes by the processor, the write data is duplicated on the data bus. so for a 16-bit data store, one copy of the data appears on the upper half of the write data bus, wdata[31:16] , and the same data appears on the lower half, wdata[15:0] . for 8-bit writes four copies are output, one on each byte lane: ? wdata[31:24] ? wdata[23:16] ? wdata[15:8] ? wdata[7:0] . this considerably eases the memory control logic design and helps overcome any endian effects. 4.11.2 reads for data reads, the processor reads a specific part of the read data bus. this is determined by: ? the endian configuration ? the size of the transfer ? bits 1 and 0 of the data address bus. table 4-13 on page 4-22 shows which bits of the data bus are read for 16-bit reads, and table 4-14 on page 4-22 shows which bits are read for 8-bit transfers. for simplicity of design, 32-bits of data can be read from memory and the processor ignores any unwanted bits.
memory interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 4-31 4.12 use of clken to control bus cycles the pipelined nature of the arm9e-s bus interface means that there is a distinction between clock cycles and bus cycles. you can use clken to stretch a bus cycle, so that it lasts for many clock cycles. the clken input extends the timing of bus cycles in increments of complete clk cycles: ?when clken is high on the rising edge of clk , a bus cycle completes ?when clken is sampled low, the bus cycle is extended. the clken input extends bus cycles on both the instruction and data interfaces when asserted. in the pipeline, the address class signals and the memory request signals are ahead of the data transfer by one bus cycle. in a system using clken this can be more than one clk cycle. this is illustrated in figure 4-12, which shows clken being used to extend a nonsequential cycle. in the example, the first n cycle is followed by another n cycle to an unrelated address, and the address for the second access is broadcast before the first access completes. figure 4-12 use of clken note when designing a memory controller, you must sample the values of inmreq , iseq , dnmreq , dseq , dmore , and the address class signals only when clken is high. this ensures that the state of the memory controller is not accidentally updated clk address class signals dnmreq, dseq, dmore rdata[31:0] (read) address 1 n cycle read data 1 first bus cycle address 2 clken next address n cycle next cycle type read data 2 second bus cycle
memory interface 4-32 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b during a waited cycle. in addition, the arm9e-s can alter the request for a subsequent memory cycle during a waited ( clken low) cycle. see withdrawal of memory requests in waited cycles . 4.12.1 withdrawal of memory requests in waited cycles the arm9e-s can alter the value of the memory request and address signals during cycles in which clken is low. this is done to improve the worst case interrupt latency of arm9e-s systems. for example, a pending memory request can be withdrawn if the core is about to take an interrupt and the access is unnecessary. the arm9e-s does not alter or withdraw any access to which it is committed . an access is said to be committed when the address and request signals are sampled on the rising edge of clk when clken is high. the arm9e-s only attempts to alter or withdraw an uncommitted access during the extended (or waited) bus cycle of a previous access. alteration of the next memory request during a waited bus cycle is shown in figure 4-13. figure 4-13 alteration of next memory request during waited bus cycle note this behavior affects the ia , inmreq , iseq , da , dnmreq , dseq , dmore , and dnspec outputs of the arm9e-s. clk address class signals dnmreq, dseq, dmore, dnspec address 1 request 1 n cycle first bus cycle clken second bus cycle ignored ignored ignored ignored internal cycle
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 5-1 chapter 5 - interrupts this chapter describes the arm9e-s interrupt behavior. it contains the following sections: ? about interrupts on page 5-2 ? hardware interface on page 5-3 ? maximum interrupt latency on page 5-7 ? minimum interrupt latency on page 5-8.
interrupts 5-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 5.1 about interrupts the arm9e-s provides a two-level, fixed-priority asynchronous hardware interrupt scheme. asynchronous is used here to mean asynchronous to the instruction flow, not to the processor clock ( clk ). refer to chapter 9 ac parameters for details on interrupt signal timing. the fast interrupt request (fiq) exception provides support for fast interrupts. the interrupt request (irq) exception provides support for normal priority interrupts. refer to exceptions on page 2-20 for more details about the programmers model for interrupts. this chapter discusses: ? issues concerning the hardware interface to the arm9e-s interrupt mechanism that a system designer must be aware of when integrating an arm9e-s system ? issues that a programmer must be aware of when writing interrupt handler routines ? the worst case and best case interrupt latency.
interrupts arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 5-3 5.2 hardware interface the hardware interrupt is described under the following headings: ? generating an interrupt ? synchronization ? re-enabling interrupts after an interrupt exception ? interrupt registers on page 5-5. 5.2.1 generating an interrupt you can make the arm9e-s take the fiq or irq exceptions (if interrupts are enabled within the core) by asserting (low) the nfiq or nirq inputs, respectively. it is essential that once asserted, the interrupt input remains asserted until the arm9e-s has completed its interrupt exception entry sequence. when an interrupt input is asserted, it must remain asserted until the arm9e-s acknowledges to the source of the interrupt that the interrupt has been taken. this acknowledgement normally occurs when the interrupt service routine accesses the peripheral causing the interrupt, for example: ? by reading an interrupt status register in the systems interrupt controller ? by writing to a clear interrupt control bit ? by writing data to, or reading data from the interrupting peripheral. 5.2.2 synchronization the nfiq and nirq inputs are synchronous inputs to the arm9e-s, and must be setup and held about the rising edge of the arm9e-s clock, clk . if interrupt events that are asynchronous to clk are present in a system, synchronization register(s) that are external to the arm9e-s are required. 5.2.3 re-enabling interrupts after an interrupt exception you must take care when re-enabling interrupts (for example at the end of an interrupt routine or with a reentrant interrupt handler). you must ensure that the original source of the interrupt has been removed before interrupts are enabled again on the arm9e-s. if you cannot guarantee this, the arm9e-s might retake the interrupt exception prematurely. when considering the timing relation of removing the source of interrupt and re-enabling interrupts on the arm9e-s, you must take into account the pipelined nature of the arm9e-s and the memory system to which it is connected. for example, the instruction that causes the removal of the interrupt request (that is, deassertion of
interrupts 5-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b nfiq or nirq ) typically does not take effect until after the memory stage of that instruction. the instruction that re-enables interrupts on the arm9e-s can cause the arm9e-s to be sensitive to interrupts as early as the execute stage of that instruction. for example, consider the following instruction sequence: str r0, [r1] ;write to interrupt controller, clearing interrupt subs pc, r14, #4 ;return from interrupt routine the execution of this code sequence is illustrated in figure 5-1. figure 5-1 retaking the fiq exception in figure 5-1, the str to the interrupt controller does not cause the deassertion of the nfiq input until cycle 4. the subs instruction causes the arm9e-s to be sensitive to interrupts during cycle 3 . because of this timing relationship, the arm9e-s retakes the fiq exception in this example. the fiqdis (and similarly irqdis ) output from the arm9e-s indicates when the arm9e-s is sensitive to the state of the nfiq ( nirq ) input (0 for sensitive, 1 for insensitive). if nfiq is asserted in the same cycle that fiqdis is low, the arm9e-s takes the fiq exception in a later cycle, even if the nfiq input is subsequently deasserted. there are several approaches that you can adopt to ensure that interrupts are not enabled too early on the arm9e-s. the best approach is highly dependent on the overall system, and can be a combination of hardware and software. clk nfiq fiqdis demw demw str r0, [r1] subs pc, r14, #4
interrupts arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 5-5 example approaches are: ? analyze the system and ensure enough instructions separate the instruction that removes the interrupt and the instruction that re-enables interrupts on the arm9e-s. ? have a software polling mechanism that reads back a status bit from the system interrupt controller until it indicates that the interrupt has been removed before re-enabling interrupts. ? have a hardware system that stalls the arm9e-s until the interrupt has been removed. 5.2.4 interrupt registers before use, the nfiq and nirq inputs are registered internally to the arm9e-s. to improve interrupt latency, the registers are not conditioned by clken , and run freely, off the system clock, clk . internally, the arm9e-s can use the registered nfiq or nirq status to prepare for interrupt entry, even if the rest of the core is being waited by clken . the registered interrupt signals can only update if clk is running. because of this, the best interrupt latency can only be achieved if clk is not stopped. this requirement is counteracted by power saving features of a system (for instance, stopping clk while waiting for a slow memory device, or a power-down mode where clk is stopped). in systems like this, you can still achieve the best interrupt latency if you replace the final disabled clk cycle with one waited ( clken = 0) cycle. figure 5-2 shows a system where clk is stopped by external clock-gating for a number of cycles. figure 5-2 stopping clk for power saving figure 5-3 on page 5-6 shows a system which achieves most of the power saving benefits of the system shown in figure 5-2, while at the same time achieving best interrupt latency. clk clken
interrupts 5-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure 5-3 using clk and clken for best interrupt latency the system shown in figure 5-3 combines clk stopping and clken waiting for best power and interrupt latency performance. clk clken
interrupts arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 5-7 5.3 maximum interrupt latency the processor samples the interrupt input pins on the rising-edge of the system clock, clk . the sampled signal is examined and can cause an interrupt in the following cases: ? whenever a new instruction is scheduled to enter the execute stage of the pipeline. ? whenever a new instruction is in the execute stage for the first cycle of its execution. here cycle refers to clk cycles with clken high. ? whenever a coprocessor instruction is being busy waited in the execute stage. ? whenever a new instruction which interlocked in the execute stage has just progressed to its first active execute cycle. if the sampled signal is asserted at the same time as a multicycle instruction has started its second or later cycle of execution, the interrupt exception entry does not start until the instruction has completed. the worst-case interrupt latency occurs when the longest possible ldm instruction incurs a data abort. the processor must enter the data abort mode before taking the interrupt so that the interrupt exception exit can occur correctly. this causes a worst-case latency of 24 cycles: ? the longest ldm instruction is one that loads all of the registers, including the pc. counting the first execute cycle as 1, the ldm takes 16 cycles. ? the last word to be transferred by the ldm is transferred in cycle 17, and the abort status for the transfer is returned in this cycle. ? if a data abort happens, the processor detects this in cycle 18 and prepares for the data abort exception entry in cycle 19. ? cycles 20 and 21 are the fetch and decode stages of the data abort entry respectively. ? during cycle 22, the processor prepares for fiq entry, issuing fetch and decode cycles in cycles 23 and 24. ? therefore, the first instruction in the fiq routine enters the execute stage of the pipeline in stage 25, giving a worst-case latency of 24 cycles.
interrupts 5-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 5.4 minimum interrupt latency the minimum latency for fiq or irq is the shortest time the request can be sampled by the input register (one cycle), plus the exception entry time (three cycles). the first interrupt instruction enters the execute pipeline stage four cycles after the interrupt is asserted.
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-1 chapter 6 - arm9e-s coprocessor interface this chapter describes the arm9e-s coprocessor interface. it contains the following sections: ? about the coprocessor interface on page 6-2 ? ldc/stc on page 6-4 ? mcr/mrc on page 6-8 ? mcrr/mrrc on page 6-10 ? interlocked mcr on page 6-12 ? interlocked mcrr on page 6-13 ? cdp on page 6-14 ? privileged instructions on page 6-16 ? busy-waiting and interrupts on page 6-17 ? coprocessor 15 mcrs on page 6-18 ? connecting coprocessors on page 6-19.
arm9e-s coprocessor interface 6-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.1 about the coprocessor interface the arm9e-s supports the connection of coprocessors. all types of arm coprocessors are supported. coprocessors determine the instructions they need to execute using a pipeline follower in the coprocessor. as each instruction arrives from memory, it enters both the arm pipeline and the coprocessor pipeline. the coprocessor determines when an instruction is being fetched by the arm9e-s, so that the instruction can be loaded into the coprocessor, and the pipeline follower advanced. the coprocessor can be run either in step with the arm9e-s pipeline, or one cycle behind, depending on the timing priorities. the implications of the two approaches are discussed in: ? coprocessor pipeline operates in step with the arm9e-s ? coprocessor pipeline one cycle behind the arm9e-s . 6.1.1 coprocessor pipeline operates in step with the arm9e-s in this case, the pipeline follower inside the coprocessor matches that of the arm9e-s exactly. this complicates the timing of key signals such as the instr and clken inputs, because these now become more heavily loaded and therefore incur more delay. for this reason, this method is only recommended for tightly integrated coprocessors such as cp15, the system coprocessor. 6.1.2 coprocessor pipeline one cycle behind the arm9e-s this method is recommended for external coprocessors. a coprocessor interface block pipelines the instruction and control signals so that the loading is reduced on these critical signals. this means that the pipeline in the coprocessor operates one cycle behind the arm9e-s pipeline. the disadvantage of this is that outputs of the coprocessor are still expected in the correct pipeline stage, as seen from the arm9e-s. the most critical signal in this situation is likely to be chsd[1:0] , the coprocessor decode handshake signal. this must return the availability of the coprocessor by the end of the decode cycle, as seen by the arm9e-s. this is equivalent to the fetch cycle of the coprocessor pipeline, and therefore there is not much time to generate this signal. this means that the design might have to insert wait states for external coprocessor accesses. there are three classes of coprocessor instructions: ? ldc / stc ? mcr / mrc ? cdp .
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-3 examples of how a coprocessor must execute these instruction classes are given in: ? ldc/stc on page 6-4 ? mcr/mrc on page 6-8 ? interlocked mcr on page 6-12 ? cdp on page 6-14. note for the sake of clarity, all timing diagrams assume a system where the coprocessor pipeline operates in step with the arm9e-s.
arm9e-s coprocessor interface 6-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.2 ldc/stc the number of words transferred is determined by how the coprocessor drives the chsd[1:0] and chse[1:0] buses. in the example arm9e-s ldc/stc cycle timing shown in figure 6-1, four words of data are transferred. figure 6-1 arm9e-s ldc/stc cycle timing as with all other instructions, the arm9e-s processor core performs the main decode using the rising edge of the clock during the decode stage. from this, the core commits to executing the instruction, and so performs an instruction fetch. the coprocessor instruction pipeline keeps in step with the arm9e-s by monitoring inmreq . a a+4 a+8 a+c go go last ignored go clk inmreq coproc cpdout[31:0] stc instr[31:0] pass latecancel dnmreq dmore coproc cpdin[31:0] ldc memory execute (go) decode write chsd[1:0] chse[1:0] da[31:0] execute (go) execute (go) execute (last) arm processor pipeline
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-5 at the rising edge of clk , if clken is high, and inmreq is low, an instruction fetch is taking place, and instr[31:0] contains the fetched instruction on the next rising edge of the clock, when clken is high. this means that: ? the last instruction fetched must enter the decode stage of the coprocessor pipeline ? the instruction in the decode stage of the coprocessor pipeline must enter its execute stage ? the fetched instruction must be sampled. in all other cases, the arm9e-s pipeline is stalled, and the coprocessor pipeline must not advance. figure 6-2 shows the timing for these signals, and indicates when the coprocessor pipeline must advance its state. in this timing diagram, coproc clock shows the effective clock applied to the pipeline follower in the coprocessor. it is derived such that the coprocessor state must only advance on rising clk edges when clken is high. the method of implementing this is dependent on the design style used, such as clock gating or register recirculating. for efficient coprocessor design, an unmodified version of clk must be applied to the execution stage of the coprocessor. this allows the coprocessor to continue executing an instruction even when the arm9e-s pipeline is stalled. figure 6-2 arm9e-s coprocessor clocking during the execute stage, the condition codes are compared with the flags to determine whether the instruction really executes or not. the output pass is asserted (high) if the instruction in the execute stage of the coprocessor pipeline: ? is a coprocessor instruction ? has passed its condition codes. clk clken coproc clock
arm9e-s coprocessor interface 6-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b if a coprocessor instruction busy-waits, pass is asserted on every cycle until the coprocessor instruction is executed. if an interrupt occurs during busy-waiting, pass is driven low, and the coprocessor stops execution of the coprocessor instruction. a further output, latecancel , cancels a coprocessor instruction when the instruction preceding it caused a data abort, or a previous instruction caused a watchpoint. latecancel can be asserted even if there is no coprocessor instruction being executed. for coprocessor instructions, latecancel is valid on the rising edge of clk on the cycle that follows the first execute cycle of the coprocessor instruction. see cdp on page 6-14 for an example of latecancel behavior. on the rising edge of the clock, the arm9e-s processor core examines the coprocessor handshake signals chsd[1:0] or chse[1:0] : ? if a new instruction is entering the execute stage in the next cycle, the core examines chsd[1:0] . ? if the currently executing coprocessor instruction requires another execute cycle, the core examines chse[1:0] . the handshake signals encode one of four states: absent if there is no coprocessor attached that can execute the coprocessor instruction, the handshake signals indicate the absent state. in this case, the arm9e-s processor core takes the undefined instruction trap. wa i t if there is a coprocessor attached that can handle the instruction, but not immediately, the coprocessor handshake signals are driven to indicate that the arm9e-s processor core must stall until the coprocessor can catch up. this is known as the busy-wait condition. in this case, the arm9e-s processor core loops in an idle state waiting for chse[1:0] to be driven to another state, or for an interrupt to occur. if chse[1:0] changes to absent, the undefined instruction trap is taken. if chse[1:0] changes to go or last, the instruction proceeds as follows. if an interrupt occurs, the arm9e-s processor core is forced out of the busy-wait state. this is indicated to the coprocessor by the pass signal going low. the instruction is restarted later and so the coprocessor must not commit to the instruction (it must not change any of the coprocessor state) until it has seen pass high, when the handshake signals indicate the go or last condition. go the go state indicates that the coprocessor can execute the instruction immediately, and that it requires another cycle of execution. both the arm9e-s processor core and the coprocessor must also consider the
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-7 state of the pass signal before actually committing to the instruction. for an ldc or stc instruction, the coprocessor instruction drives the handshake signals with go when two or more words still have to be transferred. when only one further word is to be transferred, the coprocessor drives the handshake signals with last. during the execute stage, the arm9e-s processor core outputs the address for the ldc or stc . also in this cycle, dnmreq is driven low, indicating to the memory system that a memory access is required at the data end of the device. the timing for the data on rdata[31:0] for an ldc and wdata[31:0] for an stc is shown in figure 4-1 on page 4-4. last an ldc or stc can be used for more than one item of data. if this is the case, possibly after busy waiting, the coprocessor drives the coprocessor handshake signals with a number of go states, and in the penultimate cycle drives last (last indicating that the next transfer is the final one). if there is only one transfer, the sequence is [wait,[wait,...]],last. 6.2.1 coprocessor handshake encoding table 6-1 shows how the handshake signals chsd[1:0] and chse[1:0] are encoded. table 6-1 handshake signals handshake signal chsd[1:0], chse[1:0] absent 10 wa i t 0 0 go 01 last 11
arm9e-s coprocessor interface 6-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.3 mcr/mrc mcr and mrc cycles look very similar to stc or ldc . an example is shown in figure 6-3. figure 6-3 arm9e-s mcr or mrc transfer timing first inmreq is driven low to denote that the instruction on instr[31:0] is entering the decode stage of the pipeline. this causes the coprocessor to decode the new instruction and drive chsd[1:0] as required. in the next cycle inmreq is driven low to denote that the instruction has now been issued to the execute stage. if the condition codes pass, and the instruction is to be executed, the pass signal is driven high and the chsd[1:0] handshake bus is examined by the core (it is ignored in all other cases). ignored last clk wdata[31:0] (mcr) instr[31:0] inmreq rdata[31:0] (mrc) execute (go) decode chsd[1:0] chse[1:0] memory (go) write (last) arm processor pipeline pass mcr/mrc
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-9 for any successive execute cycles the chse[1:0] handshake bus is examined. when the last condition is observed, the instruction is committed. in the case of an mcr , the wdata[31:0] bus is driven with the register data. in the case of an mrc , rdata[31:0] is sampled at the end of the arm9e-s memory stage and written to the destination register during the next cycle.
arm9e-s coprocessor interface 6-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.4 mcrr/mrrc mcrr and mrrc cycles look very similar to stc or ldc . an example is shown in figure 6-4. figure 6-4 arm9e-s mcrr or mrrc transfer timing first inmreq is driven low to denote that the instruction on instr[31:0] is entering the decode stage of the pipeline. this causes the coprocessor to decode the new instruction and drive chsd[1:0] as required. in the next cycle inmreq is driven low to denote that the instruction has now been issued to the execute stage. if the condition codes pass, and the instruction is to be executed, the pass signal is driven high and the chsd[1:0] handshake bus is examined by the core (it is ignored in all other cases). for any successive execute cycles the chse[1:0] handshake bus is examined. when the last condition is observed, the instruction proceeds to its final execute cycle. in the case of an mcrr , the wdata[31:0] bus is driven with the first register data during last go clk wdata[31:0] (mcrr) instr[31:0] inmreq rdata[31:0] (mrrc) execute (go) decode chsd[1:0] chse[1:0] execute (last) memory (last) arm processor pipeline pass mcrr/mrrc ignored data1 (rd) data2 (rn) data1 data2 write (last)
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-11 the second execute cycle, and the second register data in the memory cycle. in the case of an mrrc , rdata[31:0] is sampled at the end of the second execute and first memory cycles and written to the destination registers during the next cycle.
arm9e-s coprocessor interface 6-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.5 interlocked mcr if the data for an mcr operation is not available inside the arm9e-s pipeline during its first decode cycle, the arm9e-s pipeline interlocks for one or more cycles until the data is available. an example of this is where the register being transferred is the destination from a preceding ldr instruction. in this situation the mcr instruction enters the decode stage of the coprocessor pipeline, and remains there until it can enter the execute stage. figure 6-5 gives an example of an interlocked mcr. figure 6-5 arm9e-s interlocked mcr ignored wait clk wdata[31:0] (mcr) instr[31:0] inmreq rdata[31:0] (mrc) execute (wait) decode chsd[1:0] chse[1:0] memory write arm processor pipeline pass mcr execute (last) decode (interlock) latecancel wait last
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-13 6.6 interlocked mcrr if the data for an mcrr operation is not available inside the arm9e-s pipeline during its first decode cycle, the arm9e-s pipeline interlocks for one or more cycles until the data is available. an example of this is where the register being transferred is the destination from a preceding ldr instruction. in this situation the mcrr instruction enters the decode stage of the coprocessor pipeline, and remains there until it can enter the execute stage. figure 6-6 gives an example of an interlocked mcrr. figure 6-6 arm9e-s interlocked mcrr ignored go (ignored) clk wdata[31:0] (mcrr) instr[31:0] inmreq rdata[31:0] (mrrc) execute (go) decode chsd[1:0] chse[1:0] memory write arm processor pipeline pass mcrr execute (last) decode (interlock) latecancel go last data1 (rd) data2 (rn) data1 data2
arm9e-s coprocessor interface 6-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.7 cdp cdp instructions normally execute in a single cycle. like all the previous cycles, inmreq is driven low to signal when an instruction is entering the decode stage and again when it reaches the execute stage of the pipeline: ? if the coprocessor can accept the instruction for execution, the pass signal is driven high during the execute cycle ? if the coprocessor can execute the instruction immediately it drives chsd[1:0] with last ? if the instruction requires a busy-wait cycle, the coprocessor drives chsd[1:0] with wait and then chse[1:0] with last. figure 6-7 shows a cdp which is canceled due to the previous instruction causing a data abort. figure 6-7 arm9e-s late-canceled cdp ignored last clk instr[31:0] inmreq memory (latecancelled) execute chsd[1:0] chse[1:0] cdp: coprocessor pipeline pass cprt decode latecancel execute cdp: arm processor pipeline decode exception entry start memory ldr with data abort exception continues execute dabort
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-15 the cdp instruction enters the execute stage of the pipeline and is signaled to execute by pass . in the following cycle latecancel is asserted. this causes the coprocessor to terminate execution of the cdp instruction and prevents the cdp instruction from causing state changes to the coprocessor.
arm9e-s coprocessor interface 6-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.8 privileged instructions the coprocessor might restrict certain instructions for use in privileged modes only. to do this, the coprocessor has to track the intrans output. figure 6-8 shows how intrans changes after a mode change. figure 6-8 arm9e-s privileged instructions the first two chsd responses are ignored by the arm9e-s because it is only the final chsd response, as the instruction moves from decode into execute, that counts. this allows the coprocessor to change its response as intrans / inm changes. ignored last clk instr[31:0] inmreq chsd[1:0] chse[1:0] pass cprt latecancel execute cdp: arm processor pipeline decode execute (cycle 3) execute (cycle 2) mode change memory execute intrans /inm[4:0] old mode new mode ignored ignored write decode decode memory write
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-17 6.9 busy-waiting and interrupts the coprocessor is permitted to stall, or busy-wait, the processor during the execution of a coprocessor instruction if, for example, it is still busy with an earlier coprocessor instruction. to do so, the coprocessor associated with the decode stage instruction drives wait onto chsd[1:0] . when the instruction concerned enters the execute stage of the pipeline the coprocessor can drive wait onto chse[1:0] for as many cycles as necessary to keep the instruction in the busy-wait loop. for interrupt latency reasons, the coprocessor can be interrupted while busy-waiting, causing the instruction to be abandoned. abandoning execution is done through pass . the coprocessor must monitor the state of pass during every busy-wait cycle. if it is high, the instruction must still be executed. if it is low, the instruction must be abandoned. figure 6-9 shows a busy-waited coprocessor instruction being abandoned due to an interrupt. figure 6-9 arm9e-s busy waiting and interrupts ignored clk instr[31:0] inmreq chsd[1:0] chse[1:0] pass instr latecancel arm processor pipeline decode execute (wait) execute (wait) execute (wait) execute wait execute interrupted aban- doned exception entry execute (wait) execute (wait) execute (wait) execute (wait) coprocessor pipeline wait wait ignored
arm9e-s coprocessor interface 6-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 6.10 coprocessor 15 mcrs coprocessor 15 is typically reserved for use as a system control coprocessor. for an mcr to coprocessor 15, it is possible to transfer the coprocessor data to the coprocessor on the ia and da buses. to do this the coprocessor must drive go on the coprocessor handshake signals for a number of cycles. for each cycle that the coprocessor responds with go on the handshake signals, the coprocessor data is driven onto ia and da as shown in figure 6-10. figure 6-10 arm9e-s coprocessor 15 mcrs clk instr[31:0] inmreq mcr arm processor pipeline execute (go) execute (go) execute (last) decode memory write coproc data coproc data coproc data ignored chsd[1:0] chse[1:0] pass latecancel go go last wdata[31:0] (mcr) ia[31:1] da[31:0] iseq instr instr + 4 dnmreq dseq
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-19 6.11 connecting coprocessors a coprocessor in an arm9e-s system needs to have 32-bit connections to: ? data from memory (instruction stream and ldc ) ? write data from the arm9e-s ( mcr ) ? read data to the arm9e-s ( mrc ). 6.11.1 connecting a single coprocessor an example of how to connect a coprocessor into an arm9e-s system is shown in figure 6-11. figure 6-11 coprocessor connections the logic for figure 6-11 is as follows: on rising clk asel = not (dnmreq and dseq) and (not dnrw) bsel = (not dnmreq) and (not pass) csel = dnmreq and dseq 1 0 10 arm9e-s coprocessor memory system rdata wdata asel csel cpdout cpdin 0 1 bsel
arm9e-s coprocessor interface 6-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b note the rdata enable term (asel) is specially constructed to select the coprocessor output data during mrc and stc operations. this is to allow the connection of the etm module to the arm9e-s rdata and wdata buses while still allowing tracing of mrc and stc data. 6.11.2 connecting multiple coprocessors if you have multiple coprocessors in your system, connect the handshake signals as shown in table 6-2. you must also multiplex the output data from the coprocessors. the handshaking arrangement for a two-coprocessor system is shown in example 6-1. example 6-1 in the case of two coprocessors that have handshaking signals chsd1 , and chse1 , and chsd2 , and chse2 , respectively, the following connections are made: arm9e-s cp1 cp2 chsd[1]<= chsd1[1] andchsd2[1] chsd[0]<= chsd1[0] or chsd2[0] chse[1]<= chse1[1] andchse2[1] chse[0]<= chse1[0] or chse2[0] table 6-2 handshake signal connections signal connection pass , latecancel connect these signals to all coprocessors present in the system. chsd , chse combine the individual bit 1 of chsd , and chse by anding. combine the individual bit 0 of chsd , and chse by oring. connect the chsd , and chse inputs to the arm9e-s.
arm9e-s coprocessor interface arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 6-21 6.11.3 no external coprocessor if you are implementing a system that does not include any external coprocessors, you must tie both chsd and chse to 10 (absent). this indicates that no external coprocessors are present in the system. if any coprocessor instructions are received, they cause the processor to take the undefined instruction trap, allowing the coprocessor instructions to be emulated in software if required. the coprocessor-specific outputs from the arm9e-s must be left unconnected: ? pass ? latecancel 6.11.4 undefined instructions the arm9e-s implements full armv5te architecture undefined instruction handling. this means that any instruction defined in the arm architecture reference manual as undefined , automatically causes the arm9e-s to take the undefined instruction trap. any coprocessor instruction that is not accepted by a coprocessor also results in the arm9e-s taking the undefined instruction trap.
arm9e-s coprocessor interface 6-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-1 chapter 7 - debug interface and embeddedice-rt this chapter describes the arm9e-s debug interface in the following sections: ? about the debug interface on page 7-2 ? debug systems on page 7-3 ? debug interface signals on page 7-9 ? arm9e-s core clock domains on page 7-14 ? determining the core and system state on page 7-15. this chapter also describes the arm9e-s embeddedice-rt logic in the following sections: ? about embeddedice-rt on page 7-6 ? disabling embeddedice-rt on page 7-8 ? the debug communications channel on page 7-16 ? monitor mode debug on page 7-21.
debug interface and embeddedice-rt 7-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 7.1 about the debug interface the arm9e-s debug interface is based on ieee std. 1149.1-1990, standard test access port and boundary-scan architecture . refer to this standard for an explanation of the terms used in this chapter and for a description of the tap controller states. the arm9e-s contains hardware extensions for advanced debugging features. these make it easier to develop application software, operating systems, and the hardware itself. arm9e-s supports two modes of debug operation: ? halt mode ? monitor mode . 7.1.1 halt mode in halt mode debug, the debug extensions allow the core to be forced into debug state . in debug state, the core is stopped and isolated from the rest of the system. this allows the internal state of the core, and the external state of the system, to be examined while all other system activity continues as normal. when debug has been completed, the core and system state can be restored, and program execution resumed. 7.1.2 monitor mode on a breakpoint or watchpoint, an instruction abort or data abort is generated instead of entering halt mode debug. when used in conjunction with a debug monitor program activated by the abort exception entry, it is possible to debug the arm9e-s while allowing the execution of critical interrupt service routines. the debug monitor program typically communicates with the debug host over the arm9e-s debug communication channel. monitor mode debug is described in monitor mode debug on page 7-21.
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-3 7.2 debug systems the arm9e-s forms one component of a debug system that interfaces from the high-level debugging performed by the user to the low-level interface supported by the arm9e-s. figure 7-1 shows a typical debug system. figure 7-1 typical debug system a debug system typically has three parts: ? the debug host ? the protocol converter on page 7-4 ? the arm9e-s on page 7-4 (the debug target). the debug host and the protocol converter are system-dependent. 7.2.1 the debug host the debug host is a computer running a software debugger, such as armsd. the debug host allows you to issue high-level commands such as setting breakpoints or examining the contents of memory. host computer running arm or third-party toolkit debug host protocol converter debug host debug target for example, multi-ice development system containing arm9e-s
debug interface and embeddedice-rt 7-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 7.2.2 the protocol converter an interface, such as an rs232 or parallel connection, connects the debug host to the arm9e-s development system. the messages broadcast over this connection must be converted to the interface signals of the arm9e-s. the protocol converter performs this conversion. 7.2.3 the arm9e-s the arm9e-s has hardware extensions that ease debugging at the lowest level. the debug extensions: ? allow you to stall program execution by the core ? examine the core internal state ? examine the state of the memory system ? resume program execution. the major blocks of the arm9e-s are: arm9e-s core this is the cpu core, with hardware support for debug. embeddedice-rt logic this is a set of registers and comparators used to generate debug exceptions (such as breakpoints). this unit is described in about embeddedice-rt on page 7-6. tap controller this controls the action of the scan chains using a jtag serial interface. these blocks are shown in figure 7-2 on page 7-5.
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-5 figure 7-2 arm9e-s block diagram in halt mode debug a request on one of the external debug interface signals, or on an internal functional unit known as the embeddedice-rt logic , forces the arm9e-s into debug state. the events that activate debug are: ? a breakpoint (a given instruction fetch) ? a watchpoint (a data access) ? an external debug request ? scanned debug request (a debug request scanned into the embeddedice-rt delay control register). the internal state of the arm9e-s is examined using the jtag serial interface, that allows instructions to be serially inserted into the core pipeline without using the external data bus. so, for example, when in debug state, a store multiple ( stm ) can be inserted into the instruction pipeline, and this exports the contents of the arm9e-s registers. this data can be serially shifted out without affecting the rest of the system. arm9e-s tap controller arm9e-s core arm9e-s embeddedice-rt scan chain 2 scan chain 1
debug interface and embeddedice-rt 7-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 7.3 about embeddedice-rt the arm9e-s embeddedice-rt logic provides integrated on-chip debug support for the arm9e-s core. embeddedice-rt is programmed serially using the arm9e-s tap controller. figure 7-3 shows the relationship between the core, embeddedice-rt, and the tap controller. it only shows the signals that are pertinent to embeddedice-rt. figure 7-3 the arm9e-s, tap controller, and embeddedice-rt the embeddedice-rt logic comprises: ? two real-time watchpoint units ? two independent registers, the debug control register and the debug status register ? debug comms channel. the debug control register and the debug status register provide overall control of embeddedice-rt operation. tap embeddedice-rt processor dbgtcken dbgtms dbgtdi dbgtdo clk dbgiebkpt edbgrq dbgack dbgen dbgrng[1:0] dbgext[1:0] dbgcommrx dbgcommtx dbgdewpt dbgntrst
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-7 you can program one or both watchpoint units to halt the execution of instructions by the core. execution halts when the values programmed into embeddedice-rt match the values currently appearing on the address bus, data bus, and various control signals. note you can mask any bit so that its value does not affect the comparison. you can configure each watchpoint unit to be either a watchpoint (monitoring data accesses) or a breakpoint (monitoring instruction fetches). watchpoints and breakpoints can be data-dependent in halt mode debug. the embeddedice-rt logic can be configured into a mode of operation where watchpoints or breakpoints generate data or prefetch aborts respectively. this allows a real-time (rt) debug monitor system to debug the arm while still allowing critical fast interrupt requests to be serviced.
debug interface and embeddedice-rt 7-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 7.4 disabling embeddedice-rt you can disable embeddedice-rt by setting the dbgen input low. caution hard wiring the dbgen input low permanently disables all debug functionality. when dbgen is low, it inhibits dbgdewpt , dbgiebkpt , and edbgrq to the core, and dbgack from the arm9e-s is always low.
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-9 7.5 debug interface signals there are four primary external signals associated with the debug interface: ? dbgiebkpt , dbgdewpt , and edbgrq are system requests for the arm9e-s to enter debug state ? dbgack is used by the arm9e-s to flag back to the system that it is in debug state. 7.5.1 entry into debug state on breakpoint an instruction being fetched from memory is sampled at the end of a cycle. to apply a breakpoint to that instruction, the breakpoint signal must be asserted by the end of the same cycle. this is shown in figure 7-4. figure 7-4 breakpoint timing you can build external logic, such as additional breakpoint comparators, to extend the breakpoint functionality of the embeddedice-rt logic. you must apply their output to the dbgiebkpt input. this signal is ored with the internally-generated breakpoint signal before being applied to the arm9e-s core control logic. note the timing of the dbgiebkpt input makes it unlikely that data-dependent external breakpoints are possible. clk instr[31:0] 1 m1 e1 w1 d1 ia[31:1] 2 34 dbgiebkpt dbgack f1 m2 e2 w2 d2 f2 (mb) (eb) (wb) db fb edebug1 ddebug edebug2 breakpointed instruction b f3 (d3) (f4) (e3) (m3) (d4) (e4)
debug interface and embeddedice-rt 7-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b a breakpointed instruction is allowed to enter the execute stage of the pipeline, but any state change as a result of the instruction is prevented. all instructions prior to the breakpointed instruction complete as normal. note if a breakpointed instruction does not reach the execute stage, for instance, if an earlier instruction is a branch, then both the breakpointed instruction and breakpoint status are discarded and the arm does not enter debug state. the decode cycle of the debug entry sequence occurs during the execute cycle of the breakpointed instruction. the latched breakpoint signal forces the processor to start the debug sequence. in figure 7-4 on page 7-9 instruction b is breakpointed. the debug entry sequence is initiated when instruction b enters the execute stage. the arm completes the debug entry sequence and asserts dbgack two cycles later. 7.5.2 breakpoints and exceptions a breakpointed instruction can have a prefetch abort associated with it. if so, the prefetch abort takes priority and the breakpoint is ignored. (if there is a prefetch abort, instruction data might be invalid, the breakpoint might have been data-dependent, and as the data might be incorrect, the breakpoint might have been triggered incorrectly.) swi and undefined instructions are treated in the same way as any other instruction that can have a breakpoint set on it. therefore, the breakpoint takes priority over the swi or undefined instruction. on an instruction boundary, if there is a breakpointed instruction and an interrupt ( nirq or nfiq ), the interrupt is taken and the breakpointed instruction is discarded. when the interrupt has been serviced, the execution flow is returned to the original program. this means that the instruction which was previously breakpointed is fetched again, and if the breakpoint is still set, the processor enters debug state when it reaches the execute stage of the pipeline. when the processor has entered debug state, it is important that further interrupts do not affect the instructions executed. for this reason, as soon as the processor enters debug state, interrupts are disabled, although the state of the i and f bits in the program status register (psr) are not affected.
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-11 7.5.3 watchpoints entry into debug state following a watchpointed memory access is imprecise. this is necessary because of the nature of the pipeline. you can build external logic, such as external watchpoint comparators, to extend the functionality of the embeddedice-rt logic. you must apply their output to the dbgdewpt input. this signal is ored with the internally-generated watchpoint signal before being applied to the arm9e-s core control logic. note the timing of the dbgdewpt input makes it unlikely that data-dependent external watchpoints are possible. after a watchpointed access, the next instruction in the processor pipeline is always allowed to complete execution. where this instruction is a single-cycle data-processing instruction, entry into debug state is delayed for one cycle while the instruction completes. the timing of debug entry following a watchpointed load in this case is shown in figure 7-5. figure 7-5 watchpoint entry with data processing instruction clk instr[31:0] inmreq rdata[31:0] 1 m1 e1 w1 d1 wdata[31:0] da[31:0] 2 ldr dp 56 f1 m2 e2 w2 d2 f2 mldr eldr wldr dldr fldr mdp edp wdp ddp fdp m5 e5 w5 d5 f5 edebug1 ddebug edebug2 7 8 dbgdewpt dbgack
debug interface and embeddedice-rt 7-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b although instruction 5 enters the execute stage, it is not executed, and there is no state update as a result of this instruction. once the debugging session is complete, normal continuation involves a return to instruction 5, the next instruction in the code sequence which has not yet been executed. the instruction following the instruction that generated the watchpoint might have modified the program counter (pc). if this happens, it is not possible to determine the instruction that caused the watchpoint. a timing diagram showing debug entry after a watchpoint where the next instruction is a branch is shown in figure 7-6. figure 7-6 watchpoint entry with branch you can always restart the processor. when the processor has entered debug state, the arm9e-s core can be interrogated to determine its state. in the case of a watchpoint, the pc contains a value that is five instructions on from the address of the next instruction to be executed. therefore, if on entry to debug state, in arm state, the instruction sub pc, pc, #20 is scanned in and the processor restarted, execution flow returns to the next instruction in the code sequence. clk instr[31:0] inmreq rdata[31:0] ldr wdata[31:0] da[31:0] bx x t t+4 mldr eldr wldr dldr fldr mb eb wb db fb et dt ft edebug1 ddebug edebug2 t+8 t+c dbgdewpt dbgack ia[31:1]
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-13 7.5.4 watchpoints and exceptions if there is an abort with the data access as well as a watchpoint, the watchpoint condition is latched, the exception entry sequence is performed, and then the processor enters debug state. if there is an interrupt pending, the arm9e-s allows the exception entry sequence to occur and then enters debug state. 7.5.5 debug request a debug request can take place through the embeddedice-rt logic or by asserting the edbgrq signal. the request is registered and passed to the processor. debug request takes priority over any pending interrupt. following registering, the core enters debug state when the instruction at the execute stage of the pipeline has completely finished executing (once memory and write stages of the pipeline have completed). while waiting for the instruction to finish executing, no more instructions are issued to the execute stage of the pipeline. when a debug request occurs, the arm9e-s enters debug state even if the embeddedice-rt is configured for monitor mode debug. 7.5.6 actions of the arm9e-s in debug state once the arm9e-s is in debug state, both memory interfaces indicate internal cycles. this allows the rest of the memory system to ignore the arm9e-s and function as normal. because the rest of the system continues operation, the arm9e-s ignores aborts and interrupts. the cfgbigend signal must not be changed by the system while in debug state. if it changes, not only is there a synchronization problem, but the view of the arm9e-s seen by the programmer changes without the knowledge of the debugger. the nreset signal must also be held stable during debug. if the system applies reset to the arm9e-s ( nreset is driven low), the state of the arm9e-s changes without the knowledge of the debugger.
debug interface and embeddedice-rt 7-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 7.6 arm9e-s core clock domains the arm9e-s has a single clock, clk , that is qualified by two clock enables: ? clken controls access to the memory system ? dbgtcken controls debug operations. during normal operation, clken conditions clk to clock the core. when the arm9e-s is in debug state, dbgtcken conditions clk to clock the core. 7.6.1 clocks and synchronization if the system and test clocks are asynchronous, they must be synchronized externally to the arm9e-s macrocell. the arm multi-ice debug agent directly supports one or more cores within an asic design. to synchronize off-chip debug clocking with the arm9e-s macrocell requires a three-stage synchronizer. the off-chip device (for example, multi-ice) issues a tck signal, and waits for the rtck (returned tck ) signal to come back. synchronization is maintained because the off-chip device does not progress to the next tck until after rtck is received. figure 7-7 shows this synchronization. figure 7-7 clock synchronization d q d q d q d q d q tdo rtck tck tms tdi dbgtdo clk dbgtdi dbgtms dbgtcken clk clk arm9e-s clk tck synchronizer multi-ice interface pads input sample and hold en en
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-15 7.7 determining the core and system state when the arm9e-s is in debug state, you can examine the core and system state by forcing the load and store multiples into the instruction pipeline. before you can examine the core and system state, the debugger must determine whether the processor entered debug from thumb state or arm state, by examining bit 4 of the embeddedice-rt debug status register. if bit 4 is high, the core has entered debug from thumb state. for more details about determining the core state, see determining the core and system state on page c-18.
debug interface and embeddedice-rt 7-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 7.8 the debug communications channel the arm9e-s embeddedice-rt logic contains a communications channel for passing information between the target and the host debugger. this is implemented as coprocessor 14. the communications channel comprises: ? a 32-bit wide comms data read register ? a 32-bit wide comms data write register ? a 6-bit wide comms control register for synchronized handshaking between the processor and the asynchronous debugger. these registers are located in fixed locations in the embeddedice-rt logic register map (as shown in embeddedice-rt logic on page c-28) and are accessed from the processor using mcr and mrc instructions to coprocessor 14. in addition to the comms channel registers, the processor can access a 1-bit debug status register for use in the monitor mode debug configuration. 7.8.1 debug comms channel registers coprocessor 14 contains 4 registers, allocated as shown in table 7-1. seen from the debugger, the registers are accessed using the scan chain in the usual way. seen from the processor, these registers are accessed using coprocessor register transfer instructions. table 7-1 coprocessor 14 register map register name register number notes comms channel control c0 read only a a. you can clear bit 0 of the comms channel control register by writing to it from the debugger (jtag) side. comms channel data read c1 for reads comms channel data write c1 for writes comms channel monitor mode debug status c2 read/write
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-17 7.8.2 debug comms channel control register the debug comms channel control register is read-only. 1 the register controls synchronized handshaking between the processor and the debugger. the debug comms channel control register is shown in figure 7-8. figure 7-8 debug comms channel control register the function of each register bit is described below: bits 31:28 contain a fixed pattern that denotes the embeddedice version number (in this case 0011). bits 27:2 are reserved. bit 1 denotes if the comms data write register is available (from the viewpoint of the processor). seen from the processor, if the comms data write register is free (w=0), new data can be written. if the register is not free (w=1), the processor must poll until w=0. seen from the debugger, when w=1, some new data has been written that can then be scanned out. bit 0 denotes if there is new data in the comms data read register. seen from the processor, if r=1, there is some new data that can be read using an mrc instruction. seen from the debugger, if r=0, the comms data read register is free, and new data may be placed there through the scan chain. if r=1, this denotes that data previously placed there through the scan chain has not been collected by the processor, and so the debugger must wait. 1. the control register should be viewed as read-only. however, the debugger can clear the r bit by performing a write to the debug comms channel control register. this feature must not be used under normal circumstances. 313029282726252423222120191817161514131211109876543210 01 01 00000000000000000000000000 wr
debug interface and embeddedice-rt 7-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b you can use the following instructions to access these registers: mrc p14, 0, rd, c0, c0 this returns the debug comms control register into rd. mcr p14, 0, rn, c1, c0 this writes the value in rn to the comms data write register. mrc p14, 0, rd, c1, c0 this returns the debug data read register into rd. note the thumb instruction set does not support coprocessor instructions. therefore, the processor must be in arm state before you can access the debug comms channel. 7.8.3 comms channel monitor mode debug status register the coprocessor 14 monitor mode debug status register is provided for use by a debug monitor when the arm9e-s is configured into the monitor mode debug mode. the coprocessor 14 monitor mode debug status register is a 1-bit wide read/write register having the format shown in figure 7-9. figure 7-9 coprocessor 14 monitor mode debug status register format bit 0 of the register, the dbgabt bit, indicates whether the processor took a prefetch or data abort in the past because of a breakpoint or watchpoint. if the arm9e-s core takes a prefetch abort as a result of a breakpoint or watchpoint, then the bit is set. if on a particular instruction or data fetch, both the debug abort and external abort signals are asserted, the external abort takes priority and the dbgabt bit is not set. you can read or write the dbgabt bit using mrc or mcr instructions. 313029282726252423222120191817161514131211109876543210 00 00 00000000000000000000000000 0 dbgabt bit
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-19 a typical use of this bit is by a monitor mode debug aware abort handler. this examines the dbgabt bit to determine whether the abort was externally or internally generated. if the dbgabt bit is set, the abort handler initiates communication with the debugger over the comms channel. 7.8.4 communications using the comms channel you can send and receive messages using the comms channel. these are described in: ? sending a message to the debugger ? receiving a message from the debugger on page 7-20. sending a message to the debugger before the processor can send a message to the debugger, it must check that the comms data write register is free for use by finding out if the w bit of the debug comms control register is clear. the processor reads the debug comms control register to check the status of the w bit: ? if the w bit is clear, the comms data write register is clear. ? if the w bit is set, previously written data has not been read by the debugger. the processor must continue to poll the control register until the w bit is clear. when the w bit is clear, a message is written by a register transfer to coprocessor 14. as the data transfer occurs from the processor to the comms data write register, the w bit is set in the debug comms control register. the debugger has two options available for reading data from the comms data write register: ? poll the debug comms channel control register before reading the comms data written. if the w bit is set, there is valid data present in the debug comms data write register. the debugger can then read this data and scan the data out. the action of reading the data clears the debug comms channel control register w bit. then the communications process can begin again. ? poll the comms data write register, obtaining data and valid status. the data scanned out consists of the contents of the comms data write register (which might or might not be valid), and a flag that indicates whether the data read is valid or not. the status flag is present in the addr[0] bit position of scan chain 2 when the data is scanned out. see test data registers on page c-10 for details of scan chain 2.
debug interface and embeddedice-rt 7-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b receiving a message from the debugger transferring a message from the debugger to the processor is similar to sending a message to the debugger. in this case, the debugger polls the r bit of the debug comms control register. ? if the r bit is low, the comms data read register is free, and data can be placed there for the processor to read. ? if the r bit is set, previously deposited data has not yet been collected, so the debugger must wait. when the comms data read register is free, data is written there using the jtag interface. the action of this write sets the r bit in the debug comms control register. the processor polls the debug comms control register. if the r bit is set, there is data that can be read using an mrc instruction to coprocessor 14. the action of this load clears the r bit in the debug comms control register. when the debugger polls this register and sees that the r bit is clear, the data has been taken, and the process can now be repeated.
debug interface and embeddedice-rt arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 7-21 7.9 monitor mode debug arm9e-s contains logic that allows the debugging of a system without stopping the core entirely. this allows the continued servicing of critical interrupt routines while the core is being interrogated by the debugger. setting bit 4 of the debug control register enables the monitor mode debug features of arm9e-s. when this bit is set, the embeddedice-rt logic is configured so that a breakpoint or watchpoint causes the arm to enter abort mode, taking the prefetch or data abort vectors respectively. there are a number of restrictions you must be aware of when the arm is configured for monitor mode debugging: ? breakpoints and watchpoints cannot be data-dependent. no support is provided for use of the range functionality. breakpoints and watchpoints can only be based on: instruction or data addresses external watchpoint conditioner ( dbgextern ) user or privileged mode access ( dntrans/intrans ) read/write access (watchpoints) access size (breakpoints itbit , watchpoints dmas[1:0] ) chained comparisons. ? the single-step hardware must not be enabled. ? external breakpoints or watchpoints are not supported. ? the vector catching hardware can be used but must not be configured to catch the prefetch or data abort exceptions. ? no support is provided to mix halt mode debug and monitor mode debug functionality. the fact that an abort has been generated by the monitor mode is recorded in the monitor mode debug status register in coprocessor 14 (see comms channel monitor mode debug status register on page 7-18). because the monitor mode debug bit does not put the arm9e-s into debug state, it now becomes necessary to change the contents of the watchpoint registers while external memory accesses are taking place, rather than being changed when in debug state. in the event that the watchpoint registers are written to during an access, all matches from the affected watchpoint unit using the register being updated are disabled for the cycle of the update.
debug interface and embeddedice-rt 7-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b if there is a possibility of false matches occurring during changes to the watchpoint registers, caused by old data in some registers and new data in others, then you must: 1. disable the watchpoint unit using the control register for that watchpoint unit. 2. change the other registers. 3. re-enable the watchpoint unit by rewriting the control register.
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-1 chapter 8 - instruction cycle times this chapter gives the instruction cycle timings and illustrates interlock conditions present in the arm9e-s design. it contains the following sections: ? instruction cycle count summary on page 8-3 ? introduction to detailed instruction cycle timings on page 8-7 ? branch and arm branch with link on page 8-8 ? thumb branch with link on page 8-9 ? branch and exchange on page 8-10 ? thumb branch, link, and exchange on page 8-11 ? data operations on page 8-12 ? mrs on page 8-14 ? msr operations on page 8-15 ? multiply and multiply accumulate on page 8-16 ? qadd, qdadd, qsub, and qdsub on page 8-20 ? load register on page 8-21 ? store register on page 8-26 ? load multiple registers on page 8-27 ? store multiple registers on page 8-30 ? load double register on page 8-31
instruction cycle times 8-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b ? store double register on page 8-32 ? data swap on page 8-33 ? pld on page 8-35 ? software interrupt, undefined instruction, and exception entry on page 8-36 ? coprocessor data processing operation on page 8-37 ? load coprocessor register (from memory) on page 8-38 ? store coprocessor register (to memory) on page 8-40 ? coprocessor register transfer (to arm) on page 8-42 ? coprocessor register transfer (from arm) on page 8-43 ? double coprocessor register transfer (to arm) on page 8-44 ? double coprocessor register transfer (from arm) on page 8-45 ? coprocessor absent on page 8-46 ? unexecuted instructions on page 8-47.
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-3 8.1 instruction cycle count summary table 8-1 shows the key to the other tables in this chapter. table 8-2 summarizes the arm9e-s instruction cycle counts and bus activity when executing the arm instruction set. table 8-1 key to tables symbol meaning b the number of busy-wait states during coprocessor accesses. n the number of words transferred in an ldm / stm / ldc / stc . c coprocessor register transfer cycle (c-cycle). i internal cycle (i-cycle). n nonsequential cycle (n-cycle). s sequential cycle (s-cycle). table 8-2 arm instruction cycle counts instruction cycles instruction bus data bus comment clz 1 1s 1i all cases. data op 1 1s 1i normal case, pc not destination. data op 2 1s+1i 2i with register controlled shift, pc not destination. data op 3 2s+1n 3i pc destination register. data op 4 2s+1n+1i 4i with register controlled shift, pc destination register. ldr 1 1s 1n normal case, not loading pc. ldr 2 1s+1i 1n+1i not loading pc and following instruction uses loaded word (1 cycle load-use interlock). ldr 3 1s+2i 1n+2i loaded byte, halfword, or unaligned word used by following instruction (2-cycle load-use interlock). ldr 5 2s+2i+1n 1n+4i pc is destination register.
instruction cycle times 8-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b ldrd 2 1s+1i 1n+1s normal case. ldrd 3 1s+2i 1n+1s+1i last loaded word used by following instruction. str 1 1s 1n all cases. strd 2 1s+1i 1n+1s all cases. ldm 2 1s+1i 1s+1i loading 1 register, not the pc. ldm n 1s+(n-1)i 1n+(n-1)s loading n registers, n > 1, not loading the pc. ldm n+1 1s+ni 1n+(n-1)s+1i loading n registers, n > 1, not loading the pc, last word loaded used by following instruction. ldm n+4 2s+1n+(n+1)i 1n+(n-1)s+4i loading n registers including the pc, n > 0. ldm 5 2s+2i+1n 1n+4i load pc. stm 2 1s+1i 1n+1i storing 1 register. stm n 1s+(n-1)i 1n+(n-1)s storing n registers, n > 1. swp 2 1s+1i 2n normal case. swp 3 1s+2i 2n+1i loaded word used by following instruction. pld 1 1s 1i all cases, dnspec asserted. b , bl , bx , blx 3 2s+1n 3i all cases. swi , undefined 3 2s+1n 3i all cases. coprocessor absent b+4 2s+1n+1i+bi 4i+bi all cases. cdp b+1 1s+bi (1+b)i all cases. ldc , stc b+n 1s+(b+n-1)i bi+1n+(n-1)s all cases. mcr b+1 1s+bi bi+1c all cases. mcrr b+2 1s+(b+1)i bi+2c all cases. mrc b+1 1s+bi bi+1c normal case. mrc b+2 1s+(b+1)i (b+1)i+1c following instruction uses transferred data. table 8-2 arm instruction cycle counts (continued) instruction cycles instruction bus data bus comment
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-5 mrc (dest = pc) b+4 1s+(b+3)i (b+3)i+1c destination is pc. mrrc b+2 1s+(b+1)i bi+2c normal case. mrrc b+3 1s+(b+2)i (b+1)i+2c following instruction uses last transferred data. mrs 2 1s+1i 2i all cases. msr 1 1s 1i if only flags are updated (mask_f). msr 3 1s+2i 3i if any bits other than just the flags are updated (all masks other than mask_f). mul , mla 2 1s+1i 2i normal case. mul , mla 3 1s+2i 3i following instruction uses the result in its first execute cycle or its first memory cycle. does not apply to a multiply accumulate using result for accumulate operand. muls , mlas 4 1s+3i 4i all cases, sets flags. qadd , qdadd , qsub , qdsub 1 1s 1i normal case. qadd , qdadd , qsub , qdsub 2 1s+1i 2i following instruction uses the result in its first execute cycle. smull , umull , smlal , umlal 3 1s+2i 3i normal case. smull , umull , smlal , umlal 4 1s+3i 4i following instruction uses rdhi result in its first execute cycle or its first memory cycle. does not apply to a multiply accumulate using result for accumulate operand. smulls , umulls , smlals , umlals 5 1s+4i 5i all cases, sets flags. smulxy , smlaxy 1 1s 1i normal case. smulxy , smlaxy 2 1s+1i 2i following instruction uses the result in its first execute or its first memory cycle. does not apply to a multiply accumulate using result for accumulate operand. table 8-2 arm instruction cycle counts (continued) instruction cycles instruction bus data bus comment
instruction cycle times 8-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b smulwx , smlawx 11s 1i normal case. smulwx , smlawx 2 1s+1i 2i following instruction uses the result in its first execute or its first memory cycle. does not apply to a multiply accumulate using result for accumulate operand. smlalxy 2 1s+1i 2i normal case. smlalxy 3 1s+2i 3i following instruction uses rdhi result in its first execute cycle or its first memory cycle. does not apply to a multiply accumulate using result for accumulate operand. table 8-2 arm instruction cycle counts (continued) instruction cycles instruction bus data bus comment
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-7 8.2 introduction to detailed instruction cycle timings the pipelined architecture of arm9e-s overlaps the execution of several instructions in different pipeline stages. the tables in this section show the number of cycles required by an instruction, once that instruction has reached the execute stage of the pipeline. the instruction cycle count is the number of cycles that an instruction occupies the execute stage of the pipeline. the other pipeline stages (fetch, decode, memory, writeback) are only occupied for one cycle by any instruction (in this model, interlock cycles are grouped in with the instruction generating the data that creates the interlock condition, not the instruction dependent on the data). the request, address, and control signals on both the instruction and data interfaces are pipelined so that they are generated in the cycle before the one to which they apply, and are shown as such in the following tables. the instruction address, ia[31:1] , is incremented for prefetching instructions in most cases. the increment varies with the instruction length: ? 4 bytes in arm state ? 2 bytes in thumb state. the letter i is used to indicate the instruction length. note all cycle counts in this chapter assume zero-wait-state memory access. in a system where clken is used to add wait states, the cycle counts must be adjusted accordingly. table 8-3 shows the key to the cycle timing tables, table 8-4 to table 8-36. table 8-3 key to cycle tim ing tables symbol meaning pc the address of the branch instruction. pc the branch target address. (pc) the memory contents of that address. i 4 when in arm state, or 2 when in thumb state. - indicates that the signal is not active, and therefore not valid in this cycle. a blank entry in the table indicates that the status of the signal is not determined by the instruction in that cycle. the status of the signal is determined either by the preceding or succeeding instruction.
instruction cycle times 8-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.3 branch and arm branch with link any arm or thumb branch, and an arm branch with link operation takes three cycles: 1. during the first cycle, a branch instruction calculates the branch destination while performing a prefetch from the current pc. this prefetch is performed in all case, because by the time the decision to take the branch has been reached, it is already too late to prevent the prefetch. if the previous instruction requested a data memory access, the data is transferred in this cycle. 2. during the second cycle, the arm9e-s performs a fetch from the branch destination. if the link bit is set, the return address to be stored in r14 is calculated. 3. during the third cycle, the arm9e-s performs a fetch from the destination + i, refilling the instruction pipeline. table 8-4 branch and arm branch with link cycle tim ings cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata 1 pc n cycle (pc + 2i) - i cycle 2 pc + i s cycle (pc) - i cycle - 3 pc + 2i s cycle (pc + i) - i cycle - (pc + 2i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-9 8.4 thumb branch with link a thumb branch with link ( bl ) operation comprises two consecutive thumb instructions, and takes four cycles: 1. the first instruction acts as a simple data operation. it takes a single cycle to add the pc to the upper part of the offset, and stores the result in r14. if the previous instruction requested a data memory access, the data is transferred in this cycle. 2. the second instruction acts similarly to the arm bl instruction over three cycles: a. during the first cycle, the arm9e-s calculates the final branch target address while performing a prefetch from the current pc. b. during the second cycle, the arm9e-s performs a fetch from the branch destination, while calculating the return address to be stored in r14. c. during the third cycle, the arm9e-s performs a fetch from the destination + 2, refilling the instruction pipeline. table 8-5 shows the cycle timings of the complete operation. table 8-5 thumb branch with link cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata 1 pc+3i s cycle (pc+i) - i cycle 2 pc n cycle (pc+3i) - i cycle - 3 pc+i s cycle (pc) - i cycle - 4 pc+i s cycle (pc+i) - i cycle - (pc+i) -
instruction cycle times 8-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.5 branch and exchange a branch and exchange ( bx ), branch, link and exchange register ( blx ) or arm blx operation takes three cycles, and is similar to a branch: 1. during the first cycle, the arm9e-s extracts the branch destination and the new core state while performing a prefetch from the current pc. this prefetch is performed in all cases, because by the time the decision to take the branch has been reached, it is already too late to prevent the prefetch. in the case of bx and blx , the branch destination new state comes from the register. for blx the destination is calculated as a pc offset. the state is always changed. if the previous instruction requested a memory access (and there is no interlock in the case of bx , blx ), the data is transferred in this cycle. 2. during the second cycle, the arm9e-s performs a fetch from the branch destination, using the new instruction width, dependent on the state that has been selected. if the link bit is set, the return address to be stored in r14 is calculated. 3. during the third cycle, the arm9e-s performs a fetch from the destination +2 or +4 dependent on the new specified state, refilling the instruction pipeline. table 8-6 shows the cycle timings, where: i is the instruction width before the bx/blx instruction. i is the instruction width after the bx/blx instruction. t is the state of the itbit signal after the bx/blx instruction. table 8-6 branch and exchange cycle timing cycle ia inmreq, iseq instr itbit da dnmreq, dseq rdata/ wdata 1 pc n cycle (pc + 2i) t - i cycle 2 pc + i s cycle (pc) t - i cycle - 3 pc + 2i s cycle (pc + i) t - i cycle - (pc + 2i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-11 8.6 thumb branch, link, and exchange a thumb branch, link, and exchange immediate ( blx ) operation is similar to a thumb bl operation. it comprises two consecutive thumb instructions, and takes four cycles: 1. the first instruction acts as a simple data operation. it takes a single cycle to add the pc to the upper part of the offset, and stores the result in r14. if the previous instruction requested a data memory access, the data is transferred in this cycle. 2. the second instruction acts similarly to the arm blx instruction: a. during the first cycle, the arm9e-s calculates the final branch target address while performing a prefetch from the current pc. b. during the second cycle, the arm9e-s performs a fetch from the branch destination, using the new instruction width, dependent on the state that has been selected. the return address to be stored in r14 is calculated. c. during the third cycle, the arm9e-s performs a fetch from the destination + 4, refilling the instruction pipeline. table 8-7 shows the cycle timings of the complete operation. table 8-7 thumb branch, link and exchange cycle timing cycle ia inmreq, iseq instr itbit da dnmreq, dseq rdata/ wdata 1 pc+3i s cycle (pc+2i) t - i cycle 2 pc n cycle (pc+3i) t - i cycle - 3 pc+i s cycle (pc) t - i cycle - 4 pc+2i s cycle (pc+i) t - i cycle - (pc+2i) -
instruction cycle times 8-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.7 data operations a normal data operation executes in a single execute cycle except where the shift is determined by the contents of a register. a normal data operation requires up to two operands, that are read from the register file onto the a and b buses. the alu combines the a bus operand with the (shifted) b bus operand according to the operation specified in the instruction. the arm9e-s pipelines this result and writes it into the destination register, when required. compare and test operations do not write a result as they only affect the status flags. an instruction prefetch occurs at the same time as the data operation, and the pc is incremented. when a register specified shift is used, an additional execute cycle is needed to read the shifting register operand. the instruction prefetch occurs during this first cycle. the pc can be one or more of the register operands. when the pc is the destination, the external bus activity is affected. when the arm9e-s writes the result to the pc, the contents of the instruction pipeline are invalidated, and the arm9e-s takes the address for the next instruction prefetch from the alu rather than the incremented address. the arm9e-s refills the instruction pipeline before any further instruction execution takes place. exceptions are locked out while the pipeline is refilling. note shifted register with destination equals pc is not possible in thumb state. the data operation cycle timings are shown in table 8-8. table 8-8 data operation cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata normal 1 pc+3i s cycle (pc+2i) - i cycle (pc+3i) - dest=pc 1 pc n cycle (pc+2i) - i cycle 2 pc+ i s cycle (pc) - i cycle - 3 pc+2i s cycle (pc+i) - i cycle - (pc+ 2i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-13 shift(rs) 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i s cycle - - i cycle - (pc+3i) - shift (rs) dest=pc 1 pc+3i i cycle (pc+2i) - i cycle 2 pc n cycle - - i cycle - 3 pc+i s cycle (pc) - i cycle - 4 pc+2i s cycle (pc+i) - i cycle - (pc+2i) - table 8-8 data operation cycle timing (continued) cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata
instruction cycle times 8-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.8 mrs an mrs operation always takes two cycles to execute. the first cycle allows any pending state changes to the psr to be made. the second cycle passes the psr register through the alu so that it can be written to the destination register. note the mrs instruction can only be executed when in arm state. table 8-9 shows the mrs cycle timing. table 8-9 mrs cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i s cycle - - i cycle - (pc+3i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-15 8.9 msr operations an msr operation takes one cycle to execute if it only updates the status flags of the cpsr, and three cycles if it updates other parts of the psr. note msr instructions can only be executed in arm state. table 8-10 shows the cycle timings for msr operations. table 8-10 msr cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata msr flags 1 pc+3i s cycle (pc+2i) - i cycle (pc+3i) - msr other 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i i cycle - - i cycle - 3 pc+3i s cycle - - i cycle - (pc+3i) -
instruction cycle times 8-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.10 multiply and multiply accumulate the multiply instructions make use of special hardware that implements integer multiplication. all cycles except the last are internal. during the first (execute) stage of a multiply instruction, the multiplier and multiplicand operands are read onto the a and b buses, on which the multiplier unit is connected. the first stage of the multiplier performs booth recoding and partial product summation, using 16 bits of the multiplier operand each cycle. during the second (memory) stage of a multiply instruction, the partial product result from the execute stage is added with an optional accumulate term (read onto the c bus) and a possible feedback term from a previous multiply step for multiplications which require additional cycles. note in thumb state, only the muls and mlas operations are possible. 8.10.1 interlocks the multiply unit in arm9e-s operates in both the execute and memory stage of the pipeline. because of this, the multiplier result is not available until the end of the memory stage of the pipeline. if the following instruction requires the use of the multiplier result, then it must be interlocked so that the correct value is available. this applies to all instructions that require the multiply result for the first execute cycle or first memory cycle of the instruction except for multiply accumulate instructions using the previous multiply result as the accumulator operand. as an example, the following sequence incurs a single-cycle interlock: mul r0, r1, r2 sub r4, r0, r3 the following cycle also incurs a single-cycle interlock: mla r0, r1, r2, r3 str r0, [r8] the following example does not incur an interlock: mla r0, r1, r2, r0 mla r0, r3, r4, r0
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-17 table 8-11 shows the cycle timing for mul and mla instructions with and without interlocks. the muls and mlas instructions always take four cycles to execute, and cannot generate interlocks in following instructions. table 8-12 shows the cycle timing for muls and mlas instructions. table 8-11 mul and mla cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata normal 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i s cycle - - i cycle - (pc+3i) - interlock 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i i cycle - - i cycle - 3 pc+3i s cycle - - i cycle - (pc+3i) - table 8-12 muls and mlas cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i i cycle - - i cycle - 3 pc+3i i cycle - - i cycle - 4 pc+3i s cycle - - i cycle - (pc+3i) -
instruction cycle times 8-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b table 8-13 shows the cycle timing for smull , umull , smlal , and umlal instructions with and without interlocks. the smulls , umulls , smlals , and umlals instructions always take five cycles to execute, and cannot generate interlocks in following instructions. table 8-14 shows the cycle timing for the smulls , umulls , smlals , and umlals instructions. . table 8-13 smull, umull, smlal, and umlal cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata normal 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i i cycle - - i cycle - 3 pc+3i s cycle - - i cycle - (pc+3i) - interlock 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i i cycle - - i cycle - 3 pc+3i i cycle - - i cycle - 4 pc+3i s cycle - - i cycle - (pc+3i) - table 8-14 smulls, umulls, smlals, and umlals cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i i cycle - - i cycle - 3 pc+3i i cycle - - i cycle - 4 pc+3i i cycle - - i cycle - 5 pc+3i s cycle - - i cycle - (pc+3i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-19 table 8-15 shows the cycle timing for smulxy , smlaxy , smulwy , and smlawy instructions with and without interlocks. table 8-16 shows the cycle timing for smlalxy instructions with and without interlocks. table 8-15 smulxy, smlaxy, smulwy, and smlawy cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata normal 1 pc+3i s cycle (pc+2i) - i cycle b b (pc+3i) b - interlock 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i s cycle - - i cycle - (pc+3i) - table 8-16 smlalxy cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata normal 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i s cycle - - i cycle - (pc+3i) - interlock 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i i cycle - - i cycle 3 pc+3i s cycle - - i cycle (pc+3i) -
instruction cycle times 8-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.11 qadd, qdadd, qsub, and qdsub this class of instructions normally takes one cycle to execute and is only available in arm state. 8.11.1 interlocks the instructions in this class use both the execute and memory stages of the pipeline. because of this, the result of an instruction in this class is not available until the end of the memory stage of the pipeline. if a following instruction requires the use of the result, then it must be interlocked so that the correct value is available. this applies to all instructions that require the result for the first execute cycle. instructions that require the result of a qadd or similar instruction for the first memory cycle do not incur an interlock. as an example, the following sequence incurs a single-cycle interlock: qadd r0, r1, r2 sub r4, r0, r3 the following cycle does not incur a single-cycle interlock: qdsub r0, r1, r2 str r0, [r8] the following example does not incur an interlock: qadd r0, r4, r5 mla r0, r3, r4, r0 table 8-17 shows the cycle timing for qadd , qdadd , qsub , and qdsub instructions with and without interlocks. table 8-17 qadd, qdadd, qsub, and qdsub cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata normal 1 pc+3i s cycle (pc+2i) - i cycle (pc+3i) b - interlock 1 pc+3i i cycle (pc+2i) - i cycle 2 pc+3i s cycle - - i cycle (pc+3i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-21 8.12 load register a load register operation typically occupies the execute stage for one cycle. there might be a number of cycles before the loaded value is available for later instructions. a load to the pc occupies the execute stage for five cycles. note destination equals pc is not possible in thumb state. 8.12.1 interlocks the result of an aligned word load instruction is not available until the end of the memory stage of the pipeline. if the following instruction requires the use of this result then it must be interlocked so that the correct value is available. this interlock is referred to as a single-cycle load-use interlock. the following example incurs a single-cycle interlock: ldr r0, [r1] add r2, r0, r3 orr r4, r4, r5 the following example does not incur an interlock: ldr r0, [r1] orr r4, r4, r5 add r2, r0, r3 unaligned word loads, load byte ( ldrb ), and load halfword ( ldrh ) instructions use the byte rotate unit in the write stage of the pipeline. this introduces a two-cycle load-use interlock, that can affect the two instructions immediately following the load instruction. the following example incurs a two-cycle interlock: ldrb r0, [r1, #1] add r2, r0, r3 orr r4, r4, r5 the following example incurs a single-cycle interlock: ldrb r0, [r1, #1] orr r4, r4, r5 add r2, r0, r3 once an interlock has been incurred for one instruction it does not have to be incurred for a later instruction.
instruction cycle times 8-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b for example, the following sequence incurs a two-cycle interlock on the first add instruction, but the second add does not incur any interlocks: ldrb r0, [r1, #1] add r2, r0, r3 add r4, r0, r5 a two-cycle interlock refers to the number of unwaited arm9e-s clock cycles to which the interlock applies. if a multi-cycle instruction separates a load instruction and the instruction using the result of the load, then no interlock can apply. the following example does not incur an interlock: ldrb r0, [r1] mul r6, r7, r8 add r4, r0, r5 there is no forwarding path from loaded data to the c read port of the register bank, which is used for the store data of str and stm instructions and for the accumulate operand of multiply accumulate instructions. the result of a load must reach the write stage of the pipeline before it can be made available at the c read port, resulting in a single-cycle load-use interlock from loaded data to the c read port. the following example incurs a single-cycle interlock: ldr r0, [r1] str r0, [r2] the following example also incurs a single-cycle interlock: ldr r0, [r1] mla r2, r3, r4, r0 the following example does not incur an interlock: ldr r0, [r1] nop ** code to be changed to remove nop ** str r0, [r2] most interlock conditions are determined when the instruction being interlocked is still in the decode stage of the pipeline. load multiple and store multiple instructions can incur a decode stage interlock when the base register is not available due to a previous instruction. store multiple instructions can also incur an execute stage interlock when the first register to be stored is not available due to a previous instruction. this is referred to as a second-cycle interlock. the following example incurs a single-cycle interlock: ldr r0, [r1] stmia r0, {r1-r2}
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-23 the following example incurs a second-cycle interlock: ldr r0, [r1] stmia r2, {r0-r1} a second-cycle interlock can be incurred on the first word of data stored by an stm instruction or during the first cycle of a register controlled shift. the following example does not incur an interlock: ldr r3, [r1] stmia r0, {r2-r3} table 8-18 shows the cycle timing for basic load register operations, where: s represents the current mode-dependent value. t is either 0, when the t bit is specified in the instruction (for example ldrt ) or s at all other times. note destination equals pc is not possible in thumb state. table 8-18 load register operation cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq dntrans rdata normal 1 pc+3i s cycle (pc+2i) da n cycle t (pc+3i) (da) dest=pc 1 pc+3i i cycle (pc+2i) da n cycle t 2 pc+3i i cycle - - i cycle s (da) 3 pc n cycle (pc+3i) - i cycle s - 4 pc+i s cycle (pc) - i cycle s - 5 pc+2i s cycle (pc+i) - i cycle s - (pc+2i) -
instruction cycle times 8-24 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b table 8-19 shows the cycle timing for load operations resulting in simple interlocks. with more complicated interlock cases you cannot consider the load instruction in isolation. this is because in these cases the load instruction has vacated the execute stage of the pipeline and a later instruction has occupied it. table 8-20 shows the one-cycle interlock incurred for the following sequence of instructions: ldrb r0, [r1] nop add r2, r0, r1 table 8-19 cycle timing for load operations resulting in interlocks cycle ia inmreq, iseq instr da dnmreq, dseq rdata single-cycle interlock 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i s cycle - - i cycle (da) (pc+3i) - two-cyc le interlock 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - - i cycle (da) 3 pc+3i s cycle - - i cycle - (pc+3i) - table 8-20 example sequence ldrb, nop and add cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata ldrb r0, [r1] 1 pc+3i s cycle (pc+2i) da n cycle nop 2 pc+4i i cycle (pc+3i) - i cycle (da) 3 pc+4i s cycle - - i cycle - add r2, r0, r1 4 pc+5i s cycle (pc+4i) - i cycle - (pc+5i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-25 table 8-21 shows the cycle timing for the following code sequence: ldrb r0, [r2] stmia r3, {r0-r1} table 8-21 example sequence ldrb and stmia cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata ldrb r0, [r2] 1 pc+3i s cycle (pc+2i) da n cycle stmia r3, {r0-r1} 2 pc+4i i cycle (pc+3i) - i cycle (da) 3 pc+4i i cycle - r3 n cycle - 4 pc+4i s cycle - r3+4 s cycle r0 (pc+4i) r1
instruction cycle times 8-26 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.13 store register a store register operation executes in a single cycle. during the execute cycle, the store address is calculated, and the data to be stored is read onto the c bus. table 8-22 shows the cycle timing for a store register operation, where: s represents the current mode-dependent value. t is either 0, when the t bit is specified in the instruction (for example strt ) or s at all other times. table 8-22 store register operation cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq dntrans wdata 1 pc+3i s cycle (pc+2i) da n cycle t (pc+3i) rd
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-27 8.14 load multiple registers a load multiple ( ldm ) takes several cycles to execute, depending on the number of registers transferred and whether the pc is in the list of registers transferred. 1. during the first cycle, the arm9e-s calculates the address of the first word to be transferred, while performing an instruction prefetch. 2. during the second and subsequent cycles, arm9e-s reads the data requested in the previous cycle and calculates the address of the next word to be transferred. the new value for the base register is calculated. when a data abort occurs, the instruction continues to completion. the arm9e-s prevents all register writing after the abort. the arm9e-s restores the modified base pointer (which the load activity before the abort occurred might have overwritten). when the pc is in the list of registers to be loaded, the arm9e-s invalidates the current contents of the instruction pipeline. the pc is always the last register to be loaded, so an abort at any point prevents the pc from being overwritten. note ldm with destination = pc cannot be executed in thumb state. however, pop{rlist, pc} equates to an ldm with destination = pc . 8.14.1 interlocks an ldm instruction can cause an interlock if a following instruction is dependent on the last data value transferred. this is similar to the interlock cases present with a single word register load. there is an exception to this case for a single-word ldm where, due to the presence of an idle cycle at the end of a single-word ldm , no interlock condition exists. for example, the following sequence incurs a single-cycle interlock: ldmia r0, {r1-r2} add r3, r2, r4 the following sequence incurs a single-cycle interlock: ldmia r0, {r1-r2} str r2, [r3] the following sequence does not incur an interlock: ldmia r0, {r1} str r1, [r2]
instruction cycle times 8-28 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b the ldm cycle timings are shown in table 8-23. table 8-23 ldm cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata 1 register (not pc) 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i s cycle - - i cycle (da) (pc+3i) - n registers (n > 1) (not pc) 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - da++ s cycle (da) . pc+3i i cycle - da++ s cycle (da++) n pc+3i s cycle - da++ s cycle (da++) (pc+3i) (da++) 1 register dest=pc 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - - i cycle (da) 3 pc n cycle - - i cycle - 4 pc+i s cycle (pc) - i cycle - 5 pc+2i s cycle (pc+i) - i cycle - (pc+2i) - n registers (n > 1) (incl pc) 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - da++ s cycle (da) . pc+3i i cycle - da++ s cycle (da++) n pc+3i i cycle - da++ s cycle (da++) n + 1 pc+3i i cycle - - i cycle (da++) n + 2 pc n cycle - - i cycle - n + 3 pc+i s cycle (pc) - i cycle - n + 4 pc+2i s cycle (pc+i) - i cycle - (pc+2i) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-29 n registers (n > 1) (1 cycle interlock) 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - da++ s cycle (da) . pc+3i i cycle - da++ s cycle (da++) n pc+3i i cycle - da++ s cycle (da++) n + 1 pc+3i s cycle - - i cycle (da++) (pc+3i) - table 8-23 ldm cycle timing (continued) cycle ia inmreq, iseq instr da dnmreq, dseq rdata
instruction cycle times 8-30 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.15 store multiple registers store multiple ( stm ) instructions proceed in a similar fashion as load multiple instructions. 1. during the first cycle, the arm9e-s calculates the address of the first word to be transferred, while performing an instruction prefetch and also calculating the new value for the base register. 2. during the second and subsequent cycles, arm9e-s stores the data requested in the previous cycle and calculates the address of the next word to be transferred. when a data abort occurs, the instruction continues to completion. the arm9e-s restores the modified base pointer (which the load activity before the abort occurred might have overwritten). the stm cycle timings are shown in table 8-24. table 8-24 stm cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq wdata 1 register 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i s cycle - - i cycle r (pc+3i) - n registers (n > 1) 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - da++ s cycle r . pc+3i i cycle - da++ s cycle r n pc+3i s cycle - da++ s cycle r (pc+3i) r
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-31 8.16 load double register the ldrd instruction behaves in the same way as an ldm of two registers. refer to load multiple registers on page 8-27 and the appropriate entries in table 8-23 on page 8-28.
instruction cycle times 8-32 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.17 store double register the strd instruction behaves in the same way as an stm of two registers. refer to store multiple registers on page 8-30 and the appropriate entries in table 8-24 on page 8-30.
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-33 8.18 data swap a data swap is similar to a back-to-back load and store instruction. the data is read from external memory in the second cycle and the contents of the register are written to the external memory in the third cycle (which is merged with the first execute cycle of the next instruction). the data swapped can be a byte or word quantity. the swap operation might be aborted in either the read or the write cycle. an aborted swap operation does not affect the destination register. note data swap instructions are not available in thumb state. the dlock output of arm9e-s is driven high for both read and write cycles to indicate to the memory system that it is an atomic operation. 8.18.1 interlocks a swap operation can cause one and two-cycle interlocks in a similar fashion to a load register instruction. table 8-25 shows the cycle timing for the basic data swap operation. table 8-25 data swap cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata wdata normal 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i s cycle - da n cycle (da) - (pc+3i) - rd 1 cycle interlock 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - da n cycle (da) - 3 pc+3i s cycle - - i cycle - rd (pc+3i) - -
instruction cycle times 8-34 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 2 cycle interlock 1 pc+3i i cycle (pc+2i) da n cycle 2 pc+3i i cycle - da n cycle (da) - 3 pc+3i i cycle - - i cycle - rd 4 pc+3i s cycle - - i cycle - - (pc+3i) - - table 8-25 data swap cycle timing (continued) cycle ia inmreq, iseq instr da dnmreq, dseq rdata wdata
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-35 8.19 pld a pld operation executes in a single cycle. during the execute cycle, the prefetch address is calculated and broadcast on da[31:0] . dnmreq and dseq indicate an internal cycle, and dnspec is asserted. table 8-26 shows the cycle timings for pld instructions. table 8-26 pld operation cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata wdata 1 pc+3i s cycle (pc+2i) da i cycle (pc+3i) - -
instruction cycle times 8-36 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.20 software interrupt, undefined instruction, and exception entry exceptions, software interrupts (swis), and undefined instructions force the pc to a specific value and refill the instruction pipeline from this address: 1. during the first cycle, the arm9e-s constructs the forced address, and a mode change might take place. 2. during the second cycle, the arm9e-s performs a fetch from the exception address. the return address to be stored in r14 is calculated. the state of the cpsr is saved in the relevant spsr. 3. during the third cycle, the arm9e-s performs a fetch from the exception address + 4, refilling the instruction pipeline. the exception entry cycle timings are show in table 8-27, where: pc is one of: ? the address of the swi instruction for swis ? the address of the instruction following the last one to be executed before entering the exception for interrupts ? the address of the aborted instruction for prefetch aborts ? the address of the instruction following the one that attempted the aborted data transfer for data aborts. xn is the appropriate exception address. note the value on the instr bus can be unpredictable in the case of prefetch abort or data abort entry. table 8-27 exception entry cycle timing cycle ia inmreq, iseq intrans itbit instr da dnmreq, dseq rdata/ wdata 1 xn n cycle 1 0 - i cycle 2 xn+4 s cycle 1 0 (xn) - i cycle - 3 xn+8 s cycle 1 0 (xn+4) - i cycle - (xn+8) -
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-37 8.21 coprocessor data processing operation a coprocessor data (cdp) operation is a request from the arm9e-s for the coprocessor to initiate some action. there is no need for the coprocessor to complete the action immediately, but the coprocessor must commit to completion before driving chsd or chse to last. if the coprocessor cannot perform the requested task, it leaves chsd at absent. when the coprocessor is able to perform the task, but cannot commit immediately, the coprocessor drives chsd to wait, and in subsequent cycles drives chse to wait until able to commit, where it drives chse to last. an interrupt can cause the arm9e-s to abandon a busy-waiting coprocessor instruction (see busy-waiting and interrupts on page 6-17). note coprocessor operations are only available in arm state. the coprocessor data operation cycle timings are shown in table 8-28. table 8-28 coprocessor data operation cycle timing cycle ia ireq a instr da dreq b rdata/ wdata p c lc d chsd chse ready last 1 pc+3i s cycle (pc+2i) - i cycle 1 0 - (pc+3i) - not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 last n + 1 pc+3i s cycle - - i cycle - 1 0 - (pc+3i) - a. ireq = inmreq , iseq . b. dreq = dnmreq , dseq . c. p = pass . d. lc = latecancel .
instruction cycle times 8-38 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.22 load coprocessor register (from memory) the load coprocessor ( ldc ) operation transfers one or more words of data from memory to a coprocessor. the coprocessor commits to the transfer only when it is ready to accept the data. the coprocessor indicates that it is ready for the transfer to commence by driving chsd or chse to go. the arm9e-s produces addresses and requests data memory reads on behalf of the coprocessor, which is expected to accept the data at sequential rates. the coprocessor is responsible for determining the number of words to be transferred. it indicates this using the chsd and chse signals, setting the appropriate signal to last in the cycle before it is ready to initiate the transfer of the last data word. an interrupt can cause the arm9e-s to abandon a busy-waiting coprocessor instruction (see busy-waiting and interrupts on page 6-17). note coprocessor operations are only available in arm state. the load coprocessor register cycle timings are shown in table 8-29. table 8-29 load coprocessor register cycle timing cycle ia ireq a instr da dreq b rdata p c lc d chsd chs e 1 register ready last 1 pc+3i s cycle (pc+2i) da n cycle 1 0 - (pc+3i) (da) 1 register not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 last n+1 pc+3i s cycle - da n cycle - 1 0 - (pc+3i) (da)
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-39 m registers (m > 1) ready go 1 pc+3i i cycle (pc+2i) da n cycle 1 0 go 2 pc+3i i cycle - da++ s cycle (da) 1 0 go . pc+3i i cycle - da++ s cycle (da++) 1 0 go m-1 pc+3i i cycle - da++ s cycle (da++) 1 0 last m pc+3i s cycle - da++ s cycle (da++) 1 0 - (pc+3i) (da++) m registers (m > 1) not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 go n+1 pc+3i i cycle - da n cycle - 1 0 go n+2 pc+3i i cycle - da++ s cycle (da) 1 0 go . pc+3i i cycle - da++ s cycle (da++) 1 0 go n+ m-1 pc+3i i cycle - da++ s cycle (da++) 1 0 last n+ m pc+3i s cycle - da++ s cycle (da++) 1 0 - (pc+3i) (da++) a. ireq = inmreq , iseq . b. dreq = dnmreq , dseq . c. p = pass . d. lc = latecancel . table 8-29 load coprocessor register cycle timing (continued) cycle ia ireq a instr da dreq b rdata p c lc d chsd chs e
instruction cycle times 8-40 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.23 store coprocessor register (to memory) the store coprocessor ( stc ) operation transfers one or more words of data from a coprocessor to memory. the coprocessor commits to the transfer only when it is ready to write the data. the coprocessor indicates that it is ready for the transfer to commence by driving chsd or chse to go. the arm9e-s produces addresses and requests data memory writes on behalf of the coprocessor, which is expected to produce the data at sequential rates. the coprocessor is responsible for determining the number of words to be transferred. it indicates this using the chsd and chse signals, setting the appropriate signal to last in the cycle before it is ready to initiate the transfer of the last data word. an interrupt can cause the arm9e-s to abandon a busy-waiting coprocessor instruction (see busy-waiting and interrupts on page 6-17). note coprocessor operations are only available in arm state. the store coprocessor register cycle timings are shown in table 8-30. table 8-30 store coprocessor register cycle timing cycle ia ireq a instr da drq b rdata p c lc d chsd chse 1 register ready last 1 pc+3i s cycle (pc+2i) da n cycle 1 0 - (pc+3i) cpdata1 1 register not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 last n+1 pc+3i s cycle - da n cycle - 1 0 - (pc+3i) cpdata1
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-41 m registers (m > 1) ready go 1 pc+3i i cycle (pc+2i) da n cycle 1 0 go 2 pc+3i i cycle - da++ s cycle cpdata1 1 0 go . pc+3i i cycle - da++ s cycle cpdata 1 0 go m-1 pc+3i i cycle - da++ s cycle cpdatam-2 1 0 last m pc+3i s cycle - da++ s cycle cpdatam-1 1 0 - (pc+3i) cpdatam m registers (m > 1) not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 go n+1 pc+3i i cycle - da n cycle - 1 0 go n+2 pc+3i i cycle - da++ s cycle cpdata1 1 0 go . pc+3i i cycle - da++ s cycle cpdata 1 0 go n+m-1 pc+3i i cycle - da++ s cycle cpdatam-2 1 0 last n+m pc+3i s cycle - da++ s cycle cpdatam-1 1 0 - (pc+3i) cpdatam a. ireq = inmreq , iseq . b. drq = dnmreq , dseq . c. p = pass . d. lc = latecancel . table 8-30 store coprocessor register cycle timing (continued) cycle ia ireq a instr da drq b rdata p c lc d chsd chse
instruction cycle times 8-42 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.24 coprocessor register transfer (to arm) the move from coprocessor ( mrc ) operation transfers a single coprocessor register into the specified arm register. data is transferred over the data bus interface, in a similar fashion to a load register operation. an interrupt can cause the arm9e-s to abandon a busy-waiting coprocessor instruction (see busy-waiting and interrupts on page 6-17). note coprocessor operations are only available in arm state. the mrc instruction cycle timings are shown in table 8-31. table 8-31 mrc instruction cycle timing cycle ia ireq a instr da dreq b rdata p c lc d chsd chse ready last 1 pc+3i s cycle (pc+2i) - c cycle 1 0 - (pc+3i) cpdata not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 last n+1 pc+3i s cycle - - c cycle - 1 0 - (pc+3i) cpdata a. ireq = inmreq , iseq . b. dreq = dnmreq , dseq . c. p = pass . d. lc = latecancel .
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-43 8.25 coprocessor register transfer (from arm) the move to coprocessor ( mcr ) operation transfers a specified arm register to a coprocessor register. data is transferred over the data bus interface, in a similar fashion to a store register operation. an interrupt can cause the arm9e-s to abandon a busy-waiting coprocessor instruction (see busy-waiting and interrupts on page 6-17). note coprocessor operations are only available in arm state. the mcr instruction cycle timings are shown in table 8-32. table 8-32 mcr instruction cycle timing cycle ia ireq a instr da dreq b wdata p c lc d chsd chse ready last 1 pc+3i s cycle (pc+2i) - c cycle 1 0 - (pc+3i) rd not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 last n+1 pc+3i s cycle - - c cycle - 1 0 - (pc+3i) rd a. ireq = inmreq , iseq . b. dreq = dnmreq , dseq . c. p = pass . d. lc = latecancel .
instruction cycle times 8-44 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.26 double coprocessor register transfer (to arm) the move double from coprocessor ( mrrc ) operation transfers two coprocessor registers into the specified arm registers. data is transferred over the data bus interface, in a similar fashion to a load register operation. an interrupt can cause the arm9e-s to abandon a busy-waiting coprocessor instruction (see busy-waiting and interrupts on page 6-17). note coprocessor operations are only available in arm state. the mrrc instruction cycle timings are shown in table 8-33. table 8-33 mrrc instruction cycle timing cycle ia ireq a instr da dreq b rdata p c lc d chsd chse ready go 1 pc+3i i cycle (pc+2i) - c cycle 1 0 last 2 pc+3i s cycle - - c cycle cpdata1 1 0 - (pc+3i) cpdata2 not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 go n+1 pc+3i i cycle - - c cycle - 1 0 last n+2 pc+3i s cycle - - c cycle cpdata1 1 0 - (pc+3i) cpdata2 a. ireq = inmreq , iseq . b. dreq = dnmreq , dseq . c. p = pass . d. lc = latecancel .
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-45 8.27 double coprocessor register transfer (from arm) the move double to coprocessor ( mcrr ) operation transfers two specified arm registers to a coprocessor. data is transferred over the data bus interface, in a similar fashion to a store register operation. an interrupt can cause the arm9e-s to abandon a busy-waiting coprocessor instruction (see busy-waiting and interrupts on page 6-17). note coprocessor operations are only available in arm state. the mcrr instruction cycle timings are shown in table 8-34. table 8-34 mcrr instruction cycle timing cycle ia ireq a instr da dreq b wdata p c lc d chsd chse ready go 1 pc+3i i cycle (pc+2i) - c cycle 1 0 last pc+3i s cycle - - c cycle rd 1 0 - (pc+3i) rn not ready wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 1 0 wait n pc+3i i cycle - - i cycle - 1 0 go n+1 pc+3i i cycle - - c cycle - 1 0 last n+2 pc+3i s cycle (pc+3i) - c cycle rd 1 0 - rn a. ireq = inmreq , iseq . b. dreq = dnmreq , dseq . c. p = pass . d. lc = latecancel .
instruction cycle times 8-46 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 8.28 coprocessor absent if no coprocessor is able to process a coprocessor instruction, the instruction is treated as an undefined instruction. this allows software to emulate coprocessor instructions when no hardware coprocessor is present. note by default, chsd and chse must be driven to absent unless the coprocessor instruction is being handled by a coprocessor. coprocessor operations are only available in arm state. the cycle timings for coprocessor absent instructions are shown in table 8-35. table 8-35 coprocessor absent instruction cycle timing cycle ia ireq a inst r da dreq b rdata/ wdata p c lc d chsd chse coproces sor absent in decode absent 1 pc+3i i cycle (pc+2i) - i cycle 1 0 - - 2 0x4 n cycle - - i cycle - 0 0 - - 3 0x8 s cycle ( 0x4 ) - i cycle - 0 0 - 4 0xc s cycle ( 0x8 ) - i cycle - 0 0 - ( 0xc )- coproces sor absent in execute wa i t 1 pc+3i i cycle (pc+2i) - i cycle 1 0 wait . pc+3i i cycle - - i cycle - 0 0 wait n pc+3i i cycle - - i cycle - 0 0 absent n+1 0x4 n cycle - - i cycle - 0 0 - n+2 0x8 s cycle ( 0x4 )- i cycle - 00 n+3 0xc s cycle ( 0x8 )- i cycle - 00 ( 0xc )- a. ireq = inmreq , iseq . b. dreq = dnmreq , dseq . c. p = pass . d. lc = latecancel .
instruction cycle times arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 8-47 8.29 unexecuted instructions when the condition code of any instruction is not met, the instruction is not executed. an unexecuted instruction takes one cycle. table 8-36 shows the instruction cycle timing for an unexecuted instruction. table 8-36 unexecuted instruction cycle timing cycle ia inmreq, iseq instr da dnmreq, dseq rdata/ wdata 1 pc + 3i s cycle (pc + 2i) - i cycle (pc + 3i) -
instruction cycle times 8-48 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 9-1 chapter 9 - ac parameters this chapter gives the ac timing parameters of the arm9e-s. it contains the following sections: ? timing diagrams on page 9-2 ? ac timing parameter definitions on page 9-8.
ac parameters 9-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 9.1 timing diagrams the timing diagrams in this section are: ?figure9-1 instruction memory interface timing ?figure9-2 data memory interface timing on page 9-3 ?figure9-3 clock enable timing on page 9-3 ?figure9-4 coprocessor interface timing on page 9-4 ?figure9-5 exception and configuration timing on page 9-4 ?figure9-6 debug interface timing on page 9-5 ?figure9-7 interrupt sensitivity status timing on page 9-5 ?figure9-8 jtag interface timing on page 9-6 ?figure9-9 dbgsdout to dbgtdo relationship on page 9-7. instruction memory interface timing parameters are shown in figure 9-1. figure 9-1 instruction memory interface timing clk inmreq, iseq instr[31:0] trans intrans inm[4:0] itbit ia[31:1] address control iabort dbgiebkpt t ovitrans t ohitrans t oviaddr t ovictl t ohiaddr t ohictl t ihinstr t isinstr t ihiabort t isiabort t ihiebkpt t isiebkpt
ac parameters arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 9-3 data memory interface timing parameters are shown in figure 9-2. figure 9-2 data memory interface timing clock enable timing parameters are shown in figure 9-3. figure 9-3 clock enable timing clk dnmreq, dseq, dmore, dnspec rdata[31:0] trans dnrw, dmas[1:0], dlock, dntrans, dnm[4:0] da[31:0] address control dabort dbgdewpt t ovdtrans t ohdtrans t ovdaddr t ovdctl t ohdaddr t ohdctl t ihrdata t isrdata t ihdabort t isdabort t ihdewpt t isdewpt wdata[31:0] data t ovwdata t ohwdata clk clken t isclken t ihclken
ac parameters 9-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b coprocessor interface timing parameters are shown in figure 9-4. figure 9-4 coprocessor interface timing exception and configuration timing parameters are shown in figure 9-5. figure 9-5 exception and configuration timing clk pass chsd[1:0] latecancel t ovpass t ohpass t ovlate t ohlate t ihchsd chse[1:0] t ischsd t ihchse t ischse clk nfiq, nirq cfgbigend, cfgdisltbit, cfghivecs nreset t ihint t isint t ihcfg t iscfg t ihnreset t isnreset
ac parameters arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 9-5 debug interface timing parameters are shown in figure 9-6. figure 9-6 debug interface timing sensitive to interrupt timing parameters are shown in figure 9-7. figure 9-7 interrupt sensitivity status timing clk dbgack dbgrqi dbgrng[1:0] t ovdbgack t ohdbgack t t t t ovdbgrng ovdbgrqi ovdbgstat ovdbgcomm t t t t ohdbgrng ohdbgrqi ohdbgstat ohdbgcomm dbgen, edbgrq, dbgext[1:0] t ihdbgin t isdbgin dbginstrexec, dbginstrvalid dbgcommrx, dbgcommtx clk fiqdis, irqdis t ohintdis t ovintdis
ac parameters 9-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b jtag interface timing parameters are shown in figure 9-8. figure 9-8 jtag interface timing clk dbgir[3:0], dbgscreg[4:0], dbgtapms[3:0] dbgsdin dbgntdoen t ovdbgsm t ohdbgsm t t t ovtdoen ovsdin ovtdo t t t ohtdoen ohsdin ohtdo dbgtdo dbgntrst dbgtdi, dbgtms t ihtdi t istdi t ihntrst t isntrst dbgtcken t ihtcken t istcken tapid t ihtapid t istapid
ac parameters arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 9-7 the relationship between dbgsdout and dbgtdo is shown in figure 9-9. figure 9-9 dbgsdout to dbgtdo relationship dbgsdout dbgtdo t tdsh t tdsd
ac parameters 9-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b 9.2 ac timing parameter definitions table 9-1 shows target ac parameters. all figures are expressed as percentages of the clk period at maximum operating frequency. note where 0% is given, this indicates the hold time to clock edge plus the maximum clock skew for internal clock buffering. table 9-1 target ac timing parameters symbol parameter min max tcyc clk cycle time 100% - tisclken clken input setup to rising clk 40% - tihclken clken input hold from rising clk -0% tovitrans rising clk to instruction transaction valid - 80% tohitrans instruction transaction hold time from rising clk >0% - toviaddr rising clk to ia valid - 80% tohiaddr ia hold time from rising clk >0% - tovictl rising clk to instruction control valid - 80% tohictl instruction control hold time from rising clk >0% - tisinstr instr input setup to rising clk 20% - tihinstr instr input hold from rising clk -0% tisiabort iabort input setup to rising clk 15% - tihiabort iabort input hold from rising clk -0% tisiebkpt dbgiebkpt input setup to rising clk 15% - tihiebkpt dbgiebkpt input hold from rising clk -0% tovdtrans rising clk to data transaction valid - 70% tohdtrans data transaction hold time from clk rising >0% - tovdaddr rising clk to da valid - 80%
ac parameters arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 9-9 tohdaddr da hold time from clk rising >0% - tovdctl rising clk to data control valid - 70% tohdctl data control hold time from clk rising >0% - tovwdata rising clk to wdata valid - 20% tohwdata wdata hold time from clk rising >0% - tisrdata rdata input setup to rising clk 20% - tihrdata rdata input hold from rising clk -0% tisdabort dabort input setup to rising clk 15% - tihdabort dabort input hold from rising clk -0% tisdewpt dbgdewpt input setup to rising clk 15% - tihdewpt dbgdewpt input hold from rising clk -0% tovintdis rising clk to sensitive to interrupt status valid - 70% tohintdis sensitive to interrupt status hold from clk rising >0% - tovpass rising clk to pass valid - 40% tohpass pass hold time from clk rising >0% - tovlate rising clk to cplatecancel valid - 25% tohlate cplatecancel hold from clk rising >0% - tischsd chsd input setup to rising clk 30% - tihchsd chsd input hold from rising clk -0% tischse chse input setup to rising clk 30% - tihchse chse input hold from rising clk -0% tisint interrupt input setup to rising clk 15% - tihint interrupt input hold from rising clk -0% tisnreset nreset input setup to rising clk 25% - tihnreset nreset input hold from rising clk -0% table 9-1 target ac timing parameters (continued) symbol parameter min max
ac parameters 9-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b tiscfg configuration input setup to rising clk 20% - tihcfg configuration input hold from rising clk -0% tovdbgack clk rising to dbgack valid - 60% tohdbgack dbgack hold time from clk rising >0% - tovdbgrng clk rising to dbgrng valid - 80% tohdbgrng dbgrng hold time from clk rising >0% - tovdbgrqi clk rising to dbgrqi valid - 45% tohdbgrqi dbgrqi hold time from clk rising >0% - tovdbgstat rising clk to debug status valid - 30% tohdbgstat debug status hold from clk rising >0% - tovdbgcomm rising clk to comms channel outputs valid - 60% tohdbgcomm comms channel output hold time from rising clk >0% - tisdbgin debug inputs input setup to rising clk 35% - tihdbgin debug inputs input hold from rising clk -0% tovdbgsm clk rising to debug state valid - 30% tohdbgsm debug state hold from clk rising >0% - tovtdoen clk rising to dbgntdoen valid - 40% tohtdoen dbgntdoen hold from clk rising >0% - tovsdin clk rising to dbgsdin valid - 20% tohsdin dbgsdin hold from clk rising >0% - tovtdo clk rising to dbgtdo valid - 35% tohtdo dbgtdo hold from clk rising >0% - tisntrst dbgntrst input setup to clk rising 25% - tihntrst dbgntrst input hold from clk rising - 0% tistdi dbgtdi input setup to clk rising 25% - table 9-1 target ac timing parameters (continued) symbol parameter min max
ac parameters arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. 9-11 tihtdi dbgtdi input hold from clk rising - 0% tistcken dbgtcken input setup to clk rising 35% - tihtcken dbgtcken input hold from clk rising - 0% tistapid tapid input setup to clk rising 20% - tihtapid tapid input hold time from clk rising - 0% ttdsd dbgtdo delay from dbgsdout changing - - ttdsh dbgtdo hold time from dbgsdout changing - - table 9-1 target ac timing parameters (continued) symbol parameter min max
ac parameters 9-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. a-1 appendix a - signal descriptions this appendix lists and describes all the arm9e-s interface signals. it contains the following sections: ? clock interface signals on page a-2 ? instruction memory interface signals on page a-3 ? data memory interface signals on page a-4 ? miscellaneous signals on page a-6 ? coprocessor interface signals on page a-7 ? debug signals on page a-8.
signal descriptions a-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b a.1 clock interface signals the clock interface signals are given in table a-1. table a-1 clock interface signals name direction description clk system clock input this clock times all operations in the arm9e-s processor. all outputs change from the rising edge and all inputs are sampled on the rising edge. the clock can be stretched in either phase. synchronous wait states can be added using the clken signal. through the use of the dbgtcken signal, this clock also times debug operations. clken wait-state control input arm9e-s can be stalled for integer clock cycles by driving clken low. this signal must be held high at all other times. coreclkenout output the principal state advance signal for the arm9e-s core. this output must be connected directly to the coreclkenin input for correct operation. this signal has been exported from the core to ease buffer tree insertion from the coreclkenin input. you must take care when loading and routing the coreclkenout to coreclkenin connection. coreclkenin input this input must be connected to the coreclkenout output.
signal descriptions arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. a-3 a.2 instruction memory interface signals the instruction memory interface signals are shown in table a-2. table a-2 instruction memory interface signals name direction description ia[31:1] instruction address output the processor instruction address bus. iabort instruction abort input this is an input that allows the memory system to tell the processor that the requested instruction memory access is not allowed. instr[31:0] instruction data input this bus is used to transfer instructions between the memory system and the processor. dbgiebkpt instruction breakpoint input this is an input that allows external hardware to halt the execution of the processor for debug purposes. if high at the end of an instruction fetch it causes the arm9e-s to enter debug state if that instruction reaches the execute stage of the processor pipeline. inmreq not instruction memory request output if low at the end the cycle, then the processor requires a memory access during the following cycle. inm[4:0] instruction mode output these contain the current mode of the processor and are valid with the address. intrans not memory translate output when low the processor is in user mode, when high the processor is in a privileged mode. this signal is valid with the address. iseq instruction sequential output if high at the end of the cycle then any instruction memory access during the following cycle is sequential from the last instruction memory access. itbit instruction thumb bit output when high the processor is in thumb state, when low the processor is in arm state. this signal is valid with the address.
signal descriptions a-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b a.3 data memory interface signals the data memory interface signals are shown in table a-3. table a-3 data memory interface signals name direction description da[31:0] data address output the processor data address bus. dabort data abort input this is an input that allows the memory system to tell the processor that the requested data memory access is not allowed. rdata [31:0] read data input this bus is used to transfer data between the memory system and the processor during read cycles (when dnrw is low). wdata [31: 0] write data output this bus is used to transfer data between the memory system and the processor during write cycles (when dnrw is high). dbgdewpt data watchpoint input this is an input that allows external hardware to halt the execution of the processor for debug purposes. if high at the end of a data memory request cycle, it causes the arm9e-s to enter debug state. dlock data lock output if high, then any data memory access in the following cycle is locked, and the memory controller must wait until dlock goes low before allowing another device to access the memory. dmas[1:0] data memory access size output these encode the size of a data memory access in the following cycle. a word access is encoded as 10 (binary), a halfword access as 0l, and a byte access as 00. the encoding 11 is reserved. dmore data more output if high at the end of the cycle, then the data memory access in the following cycle is directly followed by a sequential data memory access. dnmreq not data memory request output if low at the end the cycle, then the processor requires a data memory access in the following cycle.
signal descriptions arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. a-5 dnm[4:0] data mode output the processor mode that any data memory accesses must be performed in. valid with the data address. dnrw data not read, write output if low at the end of the cycle, then any data memory access in the following cycle is a read. if high then it is a write. dnspec not data speculative request output if low at the end of the cycle, then the processor is indicating to the memory system that the data stored at the memory location specified by da might be required in subsequent cycles. dnspec is a speculative signal, so the memory system does not have to perform any action based on dnspec unless it sees fit. the memory system must return an abort for a speculative access. dnspec is not asserted in the same cycle as dnmreq . dntrans data not memory translate output if low at the end of a cycle, then any data memory access must be performed with user mode privileges. if high it must have supervisor mode privileges. dseq data sequential address output if high at the end of the cycle, then any data memory access in the following cycle is sequential from the last data memory access. table a-3 data memory interface signals (continued) name direction description
signal descriptions a-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b a.4 miscellaneous signals the miscellaneous signals are shown in table a-4. table a-4 miscellaneous signals name direction description nfiq not fast interrupt input this is the fast interrupt request signal. this input is a synchronous input to the core. it is not synchronized internally to the core. nirq not interrupt request input this is the interrupt request signal. this input is a synchronous input to the core. it is not synchronized internally to the core. cfgbigend big-endian configuration input when high, the arm9e-s processor treats bytes in memory as being in big-endian format. when it is low, memory is treated as little-endian. this is a static configuration signal. cfgdisltbit input when high, the arm9e-s disables certain armv5t defined behavior involving loading data to the pc. this input must be tied low for normal operation and full armv5t compatibility. this is a static configuration signal. cfghivecs high vectors configuration input when low, the arm9e-s exception vectors start at address 0x0000 0000 . when high the arm9e-s exception vectors start at address 0xffff 0000 . this is a static configuration signal. nreset not reset input this active low reset signal is used to start the processor from a known address. this is a level-sensitive asynchronous reset. fiqdis fiq disabled output when high, indicates that the arm9e-s is insensitive to the state of the nfiq input signal. irqdis irq disabled output when high, indicates that the arm9e-s is insensitive to the state of the nirq input signal.
signal descriptions arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. a-7 a.5 coprocessor interface signals the coprocessor interface signals are shown in table a-5. table a-5 coprocessor interface signals name direction description pass output this signal indicates that there is a coprocessor instruction in the execute stage of the pipeline, and it must be executed. chsd[1:0] coprocessor handshake decode input the handshake signals from the decode stage of the pipeline follower of the coprocessor. chse[1:0] coprocessor handshake execute input the handshake signals from the execute stage of the pipeline follower of the coprocessor. latecancel coprocessor late cancel output if high during the first memory cycle of a coprocessor instruction, then the coprocessor must cancel the instruction without changing any internal state. this signal is only asserted in cycles where the previous instruction accessed memory and a data abort occurred.
signal descriptions a-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b a.6 debug signals the debug signals are shown in table a-6. table a-6 debug signals name direction description dbgir[3:0] tap controller instruction register output these four bits reflect the current instruction loaded into the tap controller instruction register. these bits change when the tap state machine is in the update-ir state. dbgntrst not test reset input this is the active low reset signal for the embeddedice internal state. this signal is a level-sensitive asynchronous reset input. dbgntdoen not dbgtdo enable output when low, this signal denotes that serial data is being driven out on the dbgtdo output. dbgntdoen is usually used as an output enable for a dbgtdo pin in a packaged part. dbgscreg[4:0] output these five bits reflect the id number of the scan chain currently selected by the tap scan chain register controller. these bits change when the tap state machine is in the update-dr state. dbgsdin output boundary scan serial input data output this signal contains the serial data to be applied to an external scan chain. dbgsdout input boundary scan serial output data input this is the serial data out of an external scan chain. when an external boundary scan chain is not connected, this input must be tied low. dbgtapsm[3:0] tap controller state machine output this bus reflects the current state of the tap controller state machine. dbgtcken input synchronous enable for debug logic accessed using the jtag interface. dbgtdi input test data input to the debug logic. dbgtdo output output from the debug logic. dbgtms input test mode select for the tap controller.
signal descriptions arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. a-9 dbgcommrx communications channel receive output when high, this signal denotes that the comms channel receive buffer contains valid data waiting to be read by the arm9e-s. dbgcommtx communications channel transmit output when high, this signal denotes that the comms channel transmit buffer is empty. dbgack debug acknowledge output when high, indicates that the processor is in debug state. dbgen debug enable input this input signal allows the debug features of the processor to be disabled. this signal must be low when debugging is not required. dbgrqi internal debug request output this signal represents the state of bit 1 of the debug control register that is combined with edbgrq and presented to the core debug logic. edbgrq input external debug request. an external debugger may force the processor to enter debug state by asserting this signal. dbgext[1:0] embeddedice external input input this input to the embeddedice logic allows breakpoints and watchpoints to be dependent on external conditions. dbginstrexec output instruction executed. indicates that the instruction in the execute stage of the processors pipeline has been executed. dbginstrvalid output instruction valid. indicates that the instruction in the execute stage of the processors pipeline was valid and has been executed (unless it failed its conditions codes). dbgrng[1:0] embeddedice rangeout output this output indicates that the corresponding embeddedice watchpoint unit has matched the conditions currently present on the address, data and control buses. this signal is independent of the state of the enable control bit of the watchpoint unit. tapid[31:0] boundary scan id code input this input specifies the id code value shifted out on dbgtdo when the idcode instruction is entered into the tap controller. table a-6 debug signals (continued) name direction description
signal descriptions a-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. b-1 appendix b - differences between the arm9e-s and the arm9tdmi this appendix describes the differences between the arm9e-s and arm9tdmi macrocell interfaces. it contains the following sections: ? interface signals on page b-2 ? atpg scan interface on page b-5 ? timing parameters on page b-6 ? arm9e-s design considerations on page b-7 ? arm9e-s debugger considerations on page b-9.
differences between the arm9e-s and the arm9tdmi b-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b b.1 interface signals the signal names have prefixes that identify groups of functionally-related signals: cfg shows configuration inputs (typically hard-wired for an embedded application). cp shows coprocessor expansion interface signals. dbg shows scan-based embeddedice debug support input or output. other signals provide the interface for the system designer, which is primarily memory-mapped. table b-1 shows the arm9e-s signals with their arm9tdmi hard macrocell equivalent signals. table b-1 arm9e-s signals and arm9tdmi hard macrocell equivalents arm9e-s signal function arm9tdmi hard macrocell equivalent note cfgbigend 1 = big-endian configuration. 0 = little-endian configuration. bigend - cfgdisltbit 1 = disable specific armv5t behavior. 0 = enable (default). -- cfghivecs 1 = exception vectors start at 0xffff 0000 . 0 = exception vectors start at 0x0000 0000 . hivecs - clk rising edge master clock. all inputs are sampled on the rising edge of clk . all timing dependencies are from the rising edge of clk . gclk a clken system memory interface clock enable: 1 = advance the core on rising clk . 0 = prevent the core advancing on rising clk . nwait b da[31:0] 32-bit data address output bus, available in the cycle preceding the memory cycle. da[31:0] c dabort data abort. dabort d dbgcommrx embeddedice communication channel receive buffer full output. commrx - dbgcommtx embeddedice communication channel transmit buffer empty output. commtx - dbgdewpt external data watchpoint (tie low when not used). dewpt e
differences between the arm9e-s and the arm9tdmi arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. b-3 dbgext[1:0] embeddedice extern debug qualifiers (tie low when not required). extern0 , extern1 - dbgiebkpt external breakpoint (tie low when not used). iebkpt e dbginstrexec instruction executed. instrexec - dbginstrvalid instruction valid. - - dbgir[3:0] tap controller instruction register. ir[3:0] - dbgntdoen tdo enable. ntdoen f dbgntrst tap controller reset (asynchronous assertion). ntrst f dbgrng[1:0] embeddedice rangeout qualifier outputs. rangeout1 , rangeout0 - dbgrqi internal status of debug request. dbgrqi g dbgscreg[4:0] scan chain register select. screg[4:0] - dbgsdin boundary scan serial data in. sdin - dbgsdout boundary scan serial data out. sdout - dbgtapsm[3:0] tap controller state machine state. tapsm[3:0] - dbgtcken multi-ice clock input qualifier sampled on the rising edge of clk . used to qualify clk to enable the debug subsystem. - - dbgtdi test data input. tdi f dbgtdo test data output. tdo f dbgtms test mode select. tms f edbgrq external debug request. edbgrq h ia[31:1] 31-bit instruction address output bus, available in the cycle preceding the memory cycle. ia[31:1] c instr[31:0] instruction data bus used to transfer instructions between the memory system and the arm9e-s. id[31:0] - inmreq instruction memory request. inmreq c table b-1 arm9e-s signals and arm9tdmi hard macrocell equivalents (continued) arm9e-s signal function arm9tdmi hard macrocell equivalent note
differences between the arm9e-s and the arm9tdmi b-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b nfiq fast interrupt request. nfiq i nirq interrupt request. nirq i rdata[31:0] data input bus. ddin[31:0] j wdata[31:0] data output bus. this bus is always driven. dd[31:0] j a. clk is a rising edge clock. it is inverted with respect to the gclk signal used on the arm9tdmi hard macrocell. b. clken is sampled on the rising edge of clk . the nwait signal on the arm9tdmi hard macrocell must be held throughout the high phase of gclk . this means that the address class outputs ( ia[31:1] , da[31:0] , dnrw , dmas , intrans , dntrans , and itbit ) can still change in a cycle in which clken is taken low. you must take this possibility into account when designing a memory system. c. all the address class signals ( ia[31:1] , da[31:0] , dnrw , dmas , intrans , dntrans , and itbit ) change on the rising edge of clk . in a system with a low-frequency clock this means that the signals can change in the first phase of the clock cycle. this is unlike the arm9tdmi hard macrocell where they always change in the last phase of the cycle. d. the arm9tdmi featured a combinational path from dabort to dnmreq . this path does not exist in arm9e-s. e. with arm9tdmi, the breakpoint and watchpoint inputs had to be asserted in the phase 1 of the cycle following the cycle in which the data was returned from the memory system. with arm9e-s, external breakpoints and watchpoints must be returned in the same cycle as the data. f. all jtag signals are synchronous to clk on the arm9e-s. there is no asynchronous tck as on the arm9tdmi hard macrocell. an external synchronizing circuit can be used to generate tclken when an asynchronous tck is required. however, clk must be running. g. the dbgrqi signal in arm9tdmi features a combinational input to output path from edbgrq . this has been removed in arm9e-s. h. edbgrq must be synchronized externally to the macrocell. it is not an asynchronous input as on the arm9tdmi hard macrocell. i. nfiq and nirq are synchronous inputs to the arm9e-s, and are sampled on the rising edge of clk . asynchronous interrupts are not supported. j. the arm9e-s supports only unidirectional data buses, rdata[31:0] , and wdata[31:0] . when a bidirectional bus is required, you must implement external bus combining logic. table b-1 arm9e-s signals and arm9tdmi hard macrocell equivalents (continued) arm9e-s signal function arm9tdmi hard macrocell equivalent note
differences between the arm9e-s and the arm9tdmi arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. b-5 b.2 atpg scan interface where automatic scan path is inserted for automatic test pattern generation, three signals are instantiated on the macrocell interface: ? scanenable is low for normal usage, high for scan test ? scanin is the serial scan path input ? scanout is the serial scan path output.
differences between the arm9e-s and the arm9tdmi b-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b b.3 timing parameters the timing constraints have been adjusted to balance the external timing parameters with the area of the synthesized core. all inputs are sampled on the rising edge of clk . the timing diagrams associated with these timing parameters are shown in timing diagrams on page 9-2. the clock enables are sampled on every rising clock edge: ? clken setup time is t isclken , hold time is t ihclken . ? dbgtcken setup time is t istcken , hold time is t ihtcken . all other inputs are sampled on rising edge of clk when the clock enable is active high, for example: ? iabort setup time is t isiabort , hold time is t ihiabort , when clken is active. ? rdata setup time is t isrdata , hold time is t ihrdata , when clken is active. ? dbgtms , dbgtdi setup time is t istdi , hold time is t ihtdi , when dbgtcken is active. outputs are all sampled on the rising edge of clk with the appropriate clock enable active, for example: ? ia output hold time is t ohiaddr , valid time is t oviaddr when clken is active. ? inmreq, iseq output hold time is t ohitrans , valid time is t ovitrans when clken is active. similarly, all memory, coprocessor, and debug signal expansion signals are defined with input setup parameters of t is ... , hold parameters of t ih ... , output hold parameters of t oh ...and output valid parameters of t ov ... .
differences between the arm9e-s and the arm9tdmi arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. b-7 b.4 arm9e-s design considerations when an arm9tdmi hard macrocell design is being converted to arm9e-s, the following areas require special consideration: ? master clock ? jtag interface timing ? interrupt timing ? address class signal timing on page b-8 ? data aborts on page b-8. b.4.1 master clock the master clock to the arm9e-s, clk , is inverted with respect to gclk used on the arm9tdmi hard macrocell. the rising edge of the clock is the active edge of the clock, on which all inputs are sampled. all outputs are generated safely from the rising edge of clk , with the following exceptions: coreclkenout this signal can change from the rising edge of clk and has a causal relationship with clken . dbgtdo this signal can change from the rising edge of clk and has a causal relationship with dbgsdout . b.4.2 jtag interface timing all jtag signals on the arm9e-s are synchronous to the master clock input, clk . when an external tck is used, use an external synchronizer to the arm9e-s. b.4.3 interrupt timing as with all arm9e-s signals, the interrupt signals, nirq and nfiq , are sampled on the rising edge of clk . when you are converting an arm9tdmi hard macrocell design where the isync signal is asserted low, add a synchronizer to the design to synchronize the interrupt signals before they are applied to the arm9e-s.
differences between the arm9e-s and the arm9tdmi b-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b b.4.4 address class signal timing the address class outputs ( ia[31:1], da[31:0], dnrw, dmas, intrans, dntrans, and itbit ) on the arm9e-s all change in response to the rising edge of clk . this means that they can change in the first phase of the clock in some systems. when exact compatibility is required, add latches to the outside of the arm9e-s to make sure that they can change only in the second phase of the clock. because the clken signal is sampled only on the rising edge of the clock, the address class outputs still change in a cycle in which clken is low. (this is similar to the behavior of i/dnmreq and i/dseq in an arm9tdmi hard macrocell system, when a wait state is inserted using nwait .) make sure that the memory system design takes this into account. also make sure that the correct address is used for the memory cycle, even though ia/da[31:0] might have moved on to the address for the next memory cycle. for further details, refer to chapter 4 memory interface . b.4.5 data aborts the arm9tdmi featured a combinational path from dabort to dnmreq, dseq, and dmore . this path does not exist in arm9e-s. a consequence of this change is that, in the case of two back-to-back memory accesses (for example a load followed by a store), the second access is not canceled by the arm processor if the first is aborted. in these situations, the system must ignore the second memory request. for more details, see dabort on page 4-18.
differences between the arm9e-s and the arm9tdmi arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. b-9 b.5 arm9e-s debugger considerations there are a number of differences between the arm9tdmi and arm9e-s that a jtag debugger must be aware of: ? the embeddedice version number in the debug channel status register is different. see debug comms channel control register on page 7-17. ? from (test) reset, the arm9e-s is configured into monitor mode debug. a debugger requiring the arm processor halt mode debug features must clear the monitor mode enable bit in the debug control register. see debug control register on page c-34. ? there are a number of instructions that have different cycle counts on arm9e-s to arm9tdmi. in particular, the mrs instruction always requires two cycles to execute on arm9e-s. see chapter 8 instruction cycle times for more details on instruction cycle timing. ? the nv condition code cannot be used to provide a convenient single-cycle non-interlocking nop operation. this is due to arm9e-s implementing the armv5te architecture. a special opcode, 0xe320 f000 provides a guaranteed single-cycle, non-interlocking nop for arm9e-s. this opcode is using an unpredictable part of the instruction space, so that its behavior cannot be guaranteed over all arm variants.
differences between the arm9e-s and the arm9tdmi b-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-1 appendix c - debug in depth this appendix describes in further detail the debug features of the arm9e-s, and includes additional information about the embeddedice-rt logic. it contains the following sections: ? scan chains and jtag interface on page c-2 ? resetting the tap controller on page c-5 ? instruction register on page c-6 ? public instructions on page c-7 ? test data registers on page c-10 ? arm9e-s core clock domains on page c-17 ? determining the core and system state on page c-18 ? behavior of the program counter during debug on page c-24 ? priorities and exceptions on page c-27 ? embeddedice-rt logic on page c-28 ? vector catching on page c-39 ? single-stepping on page c-40 ? coupling breakpoints and watchpoints on page c-41 ? disabling embeddedice-rt on page c-44 ? embeddedice-rt timing on page c-45.
debug in depth c-2 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.1 scan chains and jtag interface there are two jtag-style scan chains within the arm9e-s. these allow debugging and embeddedice-rt programming. the scan chains allow commands to be serially shifted into the arm core, allowing the state of the core and the system to be interrogated. the jtag interface requires only five pins on the package. a jtag style test access port (tap) controller controls the scan chains. for further details of the jtag specification, refer to ieee standard 1149.1 - 1990 standard test access port and boundary-scan architecture . c.1.1 debug scan chains the two scan paths used for debug purposes are referred to as scan chain 1 and scan chain 2, and are shown in figure c-1. figure c-1 arm9e-s scan chain arrangements arm9e-s tap controller arm9e-s core arm9e-s embeddedice-rt scan chain 2 scan chain 1
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-3 scan chain 1 scan chain 1 is used for debugging the arm9e-s core when it has entered debug state. you can use it to: ? inject instructions into the arm pipeline ? read and write its registers ? perform memory accesses. scan chain 2 scan chain 2 allows access to the embeddedice-rt registers. refer to test data registers on page c-10 for details. c.1.2 tap state machine the process of serial test and debug is best explained in conjunction with the jtag state machine. figure c-2 on page c-4 shows the state transitions that occur in the tap controller. the state numbers shown in the diagram are output from the arm9e-s on the dbgtapsm[3:0] bits.
debug in depth c-4 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure c-2 test access port controller state transitions 1 1. from ieee std 1149.1-1990. copyright 1999 ieee. all rights reserved. select-dr-scan 0x7 capture-dr 0x6 shift-dr 0x2 exit1-dr 0x1 pause-dr 0x3 exit2-dr 0x0 update-dr 0x5 run-test/idle 0xc test-logic-reset 0xf tms=0 tms=0 tms=1 tms=0 tms=1 tms=1 select-ir-scan 0x4 capture-ir 0xe shift-ir 0xa exit1-ir 0x9 pause-ir 0xb exit2-ir 0x8 update-ir 0xd tms=0 tms=0 tms=1 tms=0 tms=1 tms=1 tms=0 tms=0 tms=0 tms=0 tms=1 tms=0 tms=1 tms=0 tms=1 tms=1 tms=0 tms=1 tms=1 tms=1 tms=0 tms=1 tms=0 tms=1 tms=1 tms=0
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-5 c.2 resetting the tap controller the boundary-scan interface includes a state machine controller called the tap controller. to force the tap controller into the correct state after power-up, you must apply a reset pulse to the dbgntrst signal: ? to ready the boundary-scan interface for use, drive dbgntrst low, and then high again ? to prevent the boundary-scan interface from being used, the dbgntrst input can be tied permanently low. note a clock on clk with dbgtcken high is not necessary to reset the device. the action of reset is as follows: 1. system mode is selected. this means that the boundary-scan cells do not intercept any of the signals passing between the external system and the core. 2. the idcode instruction is selected. when the tap controller is put into the shift-dr state, and clk is pulsed while enabled by dbgtcken , the contents of the id register are clocked out of dbgtdo .
debug in depth c-6 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.3 instruction register the instruction register is four bits in length. there is no parity bit. the fixed value 0001 is loaded into the instruction register during the capture-ir controller state.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-7 c.4 public instructions instructions are loaded into the tap state machine by scanning the appropriate bit pattern for the instruction when the tap controller is in the shift-ir state, and then advancing the tap controller through the update-ir state. table c-1 shows the public instructions. in the following descriptions, the arm9e-s samples dbgtdi and dbgtms on the rising edge of clk with dbgtcken high. all output transitions on dbgtdo occur as a result of the rising edge of clk with dbgtcken high. c.4.1 extest (0000) the extest instruction allows a boundary scan chain to be connected between the dbgsdin and dbgsdout pins. external logic, based on the dbgtapsm , dbgscreg , and dbgir signals is required to use the extest function for such a boundary scan chain. using extest with scan chain 1 or scan chain 2 selected is unpredictable. c.4.2 sample/preload (0011) you must use this instruction to preload the boundary scan register with known data prior to selecting intest or extest instructions. table c-1 public instructions instruction binary code extest 0000 sample/preload 0011 scan_n 0010 intest 1100 idcode 1110 bypass 1111 restart 0100
debug in depth c-8 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.4.3 scan_n (0010) the scan_n instruction connects the scan path select register between dbgtdi and dbgtdo : ? in the capture-dr state, the fixed value 1000 is loaded into the register. ? in the shift-dr state, the id number of the desired scan path is shifted into the scan path select register. ? in the update-dr state, the scan register of the selected scan chain is connected between dbgtdi and dbgtdo , and remains connected until a subsequent scan_n instruction is issued. ? on reset, scan chain 0 is selected by default. the scan path select register is 4 bits long in this implementation, although no finite length is specified. c.4.4 intest (1100) the intest instruction places the selected scan chain in test mode: ? the intest instruction connects the selected scan chain between dbgtdi and dbgtdo . ? when the intest instruction is loaded into the instruction register, all the scan cells are placed in their test mode of operation. for example, in test mode, input cells select the output of the scan chain to be applied to the core. ? in the capture-dr state, the value of the data applied from the core logic to the output scan cells, and the value of the data applied from the system logic to the input scan cells is captured. ? in the shift-dr state, the previously-captured test data is shifted out of the scan chain via the dbgtdo pin, while new test data is shifted in via the dbgtdi pin. single-step operation of the core is possible using the intest instruction.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-9 c.4.5 idcode (1110) the idcode instruction connects the device identification code register (or id register) between dbgtdi and dbgtdo . the id register is a 32-bit register that allows the manufacturer, part number, and version of a component to be read through the tap. see arm9e-s device identification (id) code register on page c-10 for details of the id register format. when the idcode instruction is loaded into the instruction register, all the scan cells are placed in their normal (system) mode of operation: ? in the capture-dr state, the device identification code is captured by the id register. ? in the shift-dr state, the previously captured device identification code is shifted out of the id register via the dbgtdo pin, while data is shifted into the id register through the dbgtdi pin. ? in the update-dr state, the id register is unaffected. c.4.6 bypass (1111) the bypass instruction connects a 1-bit shift register (the bypass register) between dbgtdi and dbgtdo . when the bypass instruction is loaded into the instruction register, all the scan cells assume their normal (system) mode of operation. the bypass instruction has no effect on the system pins: ? in the capture-dr state, a logic 0 is captured in the bypass register. ? in the shift-dr state, test data is shifted into the bypass register through dbgtdi , and shifted out through dbgtdo after a delay of one clk cycle. the first bit to shift out is a zero. ? the bypass register is not affected in the update-dr state. all unused instruction codes default to the bypass instruction. c.4.7 restart (0100) the restart instruction is used to restart the processor on exit from debug state. the restart instruction connects the bypass register between dbgtdi and dbgtdo , and the tap controller behaves as if the bypass instruction has been loaded. the processor exits debug state when the run-test/idle state is entered.
debug in depth c-10 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.5 test data registers there are six test data registers that can be selected to connect between dbgtdi and dbgtdo : ? bypass register ? id code register ? instruction register ? scan path select register ? scan chain 1 ? scan chain 2. in addition, other scan chains can be added between dbgsdout and dbgsdin , and selected when in intest mode. in the following descriptions, data is shifted during every clk cycle when dbgtcken enable is high. c.5.1 bypass register purpose bypasses the device during scan testing by providing a path between dbgtdi and dbgtdo . length 1 bit. operating mode when the bypass instruction, or any undefined instruction, is the current instruction in the instruction register, serial data is transferred from dbgtdi to dbgtdo in the shift-dr state with a delay of one clk cycle enabled by dbgtcken . a logic 0 is loaded from the parallel input of the bypass register in the capture-dr state. there is no parallel output from the bypass register. c.5.2 arm9e-s device identification (id) code register purpose reads the 32-bit device identification code. no programmable supplementary identification code is provided. length 32 bits. the format of the id register is shown in figure c-3 on page c-11. the 32-bit device identification code is loaded into the register from the parallel inputs of the tapid[31:0] input pins during the capture-dr state.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-11 the recommended generic value for tapid[31:0] in a base arm9e-s implementation is 0x15900f0f . figure c-3 id code register format note ieee standard 1149.1 requires that bit 0 of the id register be set to 1. operating mode when the idcode instruction is current, the id register is selected as the serial path between dbgtdi and dbgtdo . there is no parallel output from the id register. the 32-bit device identification code is loaded into the id register from its parallel inputs during the capture-dr state. c.5.3 instruction register purpose specifies a tap instruction. length 4 bits. operating mode in the shift-ir state, the instruction register is selected as the serial path between dbgtdi and dbgtdo . during the capture-ir state, the binary value b0001 is loaded into this register. this value is shifted out during shift-ir (least significant bit first), while a new instruction is shifted in (least significant bit first). during the update-ir state, the value in the instruction register specifies the current instruction. on reset, idcode specifies the current instruction. 313029282726252423222120191817161514131211109876543210 1 version part number manufacturer identity
debug in depth c-12 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.5.4 scan path select register purpose changes the current active scan chain. length 5 bits. operating mode scan_n as the current instruction in the shift-dr state selects the scan path select register as the serial path between dbgtdi and dbgtdo . during the capture-dr state, the value b10000 is loaded into this register. this value is shifted out during shift-dr (least significant bit first), while a new value is shifted in (least significant bit first). during the update-dr state, the value in the scan path select register selects a scan chain to become the currently active scan chain. all further instructions such as intest then apply to that scan chain. the currently selected scan chain changes only when a scan_n instruction is executed, or when a reset occurs. on reset, scan chain 3 is selected as the active scan chain. the number of the currently-selected scan chain is reflected on the dbgscreg[4:0] output bus. you can use the tap controller to drive external chains in addition to those within the arm9e-s macrocell. the external scan chain is connected between dbgsdin and dbgsdout , and must be assigned a number. the control signals are derived from dbgscreg[4:0] , dbgir[4:0] , dbgtapsm[3:0] and the clock, clk , and clock enable, dbgtcken . table c-2 lists the scan chain numbers allocated by arm. table c-2 scan chain number allocation scan chain number function 0 reserved 1debug 2 embeddedice-rt programming
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-13 the scan chain present between dbgsdin and dbgsdout is connected between dbgtdi and dbgtdo whenever scan chain 3 is selected, or when any unassigned scan chain number is selected. if there is more than one external scan chain, a multiplexor must be built externally to apply the desired scan chain output to dbgsdout . the multiplexor can be controlled by decoding dbgscreg[4:0] . c.5.5 scan chains 1 and 2 the scan chains allow serial access to the core logic and to the embeddedice hardware for programming purposes. each scan chain cell is simple, and comprises a serial register and a multiplexor. a typical cell is shown in figure c-4. figure c-4 typical scan chain cell 3 external boundary scan 4C15 reserved 16C31 unassigned table c-2 scan chain number allocation (continued) scan chain number function test mode select shift enable serial data in serial data out 1 0 1 0 clk
debug in depth c-14 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b the scan cells perform three basic functions: ? capture ?shift ? update. for input cells, the capture stage involves copying the value of the system input to the core into the serial register. during shift, this value is output serially. the value applied to the core from an input cell is either the system input or the contents of the parallel register (loads from the shift register after update-dr state) under multiplexor control. for output cells, capture involves placing the value of a core output into the serial register. during shift, this value is serially output as before. the value applied to the system from an output cell is either the core output or the contents of the serial register. all the control signals for the scan cells are generated internally by the tap controller. the action of the tap controller is determined by current instruction and the state of the tap state machine. scan chain 1 purpose scan chain 1 is used for communication between the debugger and the arm9e-s core. it is used to read and write data, and to scan instructions into the instruction pipeline. the scan_n instruction is used to select scan chain 1. length 67 bits. scan chain 1 provides serial access to rdata[31:0] when the core is doing a read, and to the wdata[31:0] bus when the core is doing a write. it also provides serial access to the instr[31:0] bus, and to the control bits, syspeed and wptandbkpt. for compatibility with the arm9tdmi, there is one additional unused bit that must be zero when writing, and is unpredictable when reading. there are 67 bits in this scan chain, the order being (from serial data in to out): 1. instr[31:0] 2. syspeed 3. wptandbkpt 4. unused bit 5. rdata[31:0] or wdata[31:0] . bit 0 of rdata or wdata is therefore the first bit to be shifted out.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-15 table c-3 shows the bit allocations for scan chain 1. the scan chain order is the same as for the arm9tdmi. the unused bit is to retain compatibility with arm9tdmi. the two control bits serve the following purposes: ? while debugging, the value placed in the sysspeed control bit determines whether the arm9e-s synchronizes back to system speed before executing the instruction. see system speed access on page c-26 for further details. ? after the arm9e-s has entered debug state, the first time sysspeed is captured and scanned out, its value tells the debugger whether the core has entered debug state from a breakpoint (sysspeed low), or a watchpoint (sysspeed high). if the instruction directly following one which causes a watchpoint has a breakpoint set on it, then the wptandbkpt bit is set. this situation does not affect how to restart the code. ? for a read the data value taken from the 32 bits in the scan chain allocated for data is used to deliver the rdata[31:0] value to the core. ? when a write is being performed by the processor the wdata[31:0] value is returned in the data part of the scanned out value. table c-3 scan chain 1 bit order bit number function type 66 rdata[0] /wdata[0] bidir ... ... bidir 35 rdata[31] /wdata[31] bidir 34 unused - 33 wptandbkpt input 32 sysspeed input 31 instr[31] input ... ... input 0 instr[0] input
debug in depth c-16 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b scan chain 2 purpose scan chain 2 allows access to the embeddedice registers. to do this, scan chain 2 must be selected using the scan_n instruction, and then the tap controller instruction must be changed to intest. length 38 bits. scan chain order from dbgtdi to dbgtdo . read/write, register address bits 4 to 0, data values bits 31 to 0. no action occurs during capture-dr. during shift-dr, a data value is shifted into the serial register. bits 32 to 36 specify the address of the embeddedice register to be accessed. during update-dr, this register is either read or written depending on the value of bit 37 (0 = read, 1 = write).
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-17 c.6 arm9e-s core clock domains the arm9e-s has a single clock, clk , that is qualified by two clock enables: ? clken controls access to the memory system ? dbgtcken controls debug operations. during normal operation, clken conditions clk to clock the core. when the arm9e-s is in debug state, dbgtcken conditions clk to clock the core.
debug in depth c-18 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.7 determining the core and system state when the arm9e-s is in debug state, you can examine the core and system state by forcing the load and store multiples into the instruction pipeline. before examining the core and system state, the debugger must determine whether the processor entered debug from thumb state or arm state by examining bit 4 of the embeddedice-rt debug status register. when bit 4 is high, the core has entered debug from thumb state. when bit 4 is low the core has entered debug from arm state. c.7.1 determining the core state when the processor has entered debug state from thumb state, the simplest method is for the debugger to force the core back into arm state. the debugger can then execute the same sequence of instructions to determine the processor state. to force the processor into arm state, execute the following sequence of thumb instructions on the core (with the sysspeed bit set low): str r0, [r1]; save r0 before use mov r0, pc ; copy pc into r0 str r0, [r1]; now save the pc in r0 bx pc ; jump into arm state mov r8, r8 ; nop mov r8, r8 ; nop note because all thumb instructions are only 16 bits long, the simplest method, when shifting scan chain 1, is to repeat the instruction. for example, the encoding for bx r0 is 0x4700 , so when 0x47004700 shifts into scan chain 1, the debugger does not have to keep track of the half of the bus on which the processor expects to read the data. you can use the sequences of arm instructions shown in example c-1 on page c-19 to determine the processor state. with the processor in the arm state, typically the first instruction to execute is: stmia r0, {r0-r15} this instruction causes the contents of the registers to appear on the data bus. you can then sample and shift out these values.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-19 note the use of r0 as the base register for the stm is only for illustration, and you can use any register. after you have determined the values in the bank of registers available in the current mode, you might want to access the other banked registers. to do this, you must change mode. normally, a mode change can occur only if the core is already in a privileged mode. however, while in debug state, a mode change can occur from any mode into any other mode. the debugger must restore the original mode before exiting debug state. for example, if the debugger has been requested to return the state of the user mode registers and fiq mode registers, and debug state is entered in supervisor mode, the instruction sequence can be as shown in example c-1. example c-1 determining the core state stmia r0, {r0-r15}; save current registers mrs r0, cpsr str r0, [r0]; save cpsr to determine current mode bic r0, 0x1f; clear mode bits orr r0, 0x10; select user mode msr cpsr, r0; enter user mode stmia r0, {r13,r14}; save registers not previously visible orr r0, 0x01; select fiq mode msr cpsr, r0; enter fiq mode stmia r0, {r8-r14}; save banked fiq registers all these instructions execute at debug speed. debug speed is much slower than system speed. this is because between each core clock, 67 clocks occur in order to shift in an instruction, or shift out data. executing instructions this slowly is acceptable for accessing the core state because the arm9e-s is fully static. however, you cannot use this method for determining the state of the rest of the system. while in debug state, you can only scan the following arm or thumb instructions into the instruction pipeline for execution: ? all data processing operations ? all load, store, load multiple, and store multiple instructions ? msr and mrs ? b , bl , and bx .
debug in depth c-20 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.7.2 determining the system state to meet the dynamic timing requirements of the memory system, any attempt to access system state must occur synchronously. therefore, the arm9e-s must be forced to synchronize back to system speed. bit 32 of scan chain 1, sysspeed, controls this. you can place a legal debug instruction onto the instruction data bus of scan chain 1 with bit 32 (the sysspeed bit) low. this instruction is then executed at debug speed. to execute an instruction at system speed, a nop (such as mov r0, r0 ) must be scanned in as the next instruction with bit 32 set high. after the system speed instructions are scanned into the instruction data bus and clocked into the pipeline, the restart instruction must be loaded into the tap controller. this causes the arm9e-s automatically to resynchronize back to clk conditioned with clken when the tap controller enters run-test/idle state, and executes the instruction at system speed. debug state is reentered once the instruction completes execution, when the processor switches itself back to clk conditioned with dbgtcken . when the instruction completes, dbgack is high. at this point intest can be selected in the tap controller, and debugging can resume. to determine if a system speed instruction has completed, the debugger must look at syscomp (bit 3 of the debug status register). the arm9e-s must access memory through the data data bus interface, as this access can be stalled indefinitely by clken . therefore, the only way to determine if the memory access has completed is to examine the syscomp bit. when this bit is high, the instruction has completed. the state of the system memory can be fed back to the debug host by using system speed load multiples and debug speed store multiples. instructions that can have the sysspeed bit set there are restrictions on which instructions can have the sysspeed bit set. the valid instructions on which to set this bit are: ? loads ?stores ? load multiple ? store multiple. when the arm9e-s returns to debug state after a system speed access, the sysspeed bit is set low. the state of this bit gives the debugger information about why the core entered debug state the first time this scan chain is read.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-21 c.7.3 exit from debug state leaving debug state involves: ? restoring the internal state of the arm9e-s ? causing a branch to the next instruction to be executed ? synchronizing back to clk conditioned with clken . after restoring the internal state, a branch instruction must be loaded into the pipeline. see behavior of the program counter during debug on page c-24 for details on calculating the branch. the sysspeed bit of scan chain 1 forces the arm9e-s to resynchronize back to clk conditioned with clken . the penultimate instruction in the debug sequence is a branch to the instruction at which execution is to resume. this is scanned in with bit 32 (sysspeed) set low. the final instruction to be scanned in is a nop (such as mov r0, r0 ), with bit 32 set high. the core is then clocked to load this instruction into the pipeline. next, the restart instruction is selected in the tap controller. when the state machine enters the run-test/idle state, the scan chain reverts back to system mode, and clock resynchronization to clk conditioned with clken occurs within the arm9e-s. normal operation then resumes, with instructions being fetched from memory. the delay, waiting until the state machine is in run-test/idle state, allows conditions to be set up in other devices in a multiprocessor system without taking immediate effect. then, when run-test/idle state is entered, all the processors resume operation simultaneously. the function of dbgack is to tell the rest of the system when the arm9e-s is in debug state. you can use this signal to inhibit peripherals such as watchdog timers that have real-time characteristics. also, you can use dbgack to mask out memory accesses that are caused by the debugging process. for example, when the arm9e-s enters debug state after a breakpoint, the instruction pipeline contains the breakpointed instruction plus two other instructions that have been prefetched. on entry to debug state, the pipeline is flushed. so, on exit from debug state, the pipeline must be refilled to its previous state. therefore, because of the debugging process, more memory accesses occur than are normally expected. it is possible, using the dbgack signal and a small amount of external logic, for a peripheral which is sensitive to the number of memory accesses to return the same result with and without debugging. note you can only use dbgack in such a way using breakpoints. it does not mask the correct number of memory accesses after a watchpoint.
debug in depth c-22 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b for example, consider a peripheral that simply counts the number of instruction fetches. this device must return the same answer after a program has run both with and without debugging. figure c-5 shows the behavior of the arm9e-s on exit from debug state. figure c-5 debug exit sequence in figure c-6 on page c-23, you can see that two instructions are fetched after the instruction which breakpoints. figure c-5 shows that dbgack masks the first three instruction fetches out of the debug state, corresponding to the breakpoint instruction, and the two instructions prefetched after it. under some circumstances dbgack can remain high for more than three instruction fetches. therefore, if you require precise instruction access counting, you must provide some external logic to generate a modified dbgack that always falls after three instruction fetches. note when system speed accesses occur, dbgack remains high throughout. it then falls after the system speed memory accesses are completed, and finally rises again as the processor reenters debug state. therefore, dbgack masks all system speed memory accesses. nss clk inmreq iseq ia[31:1] dbgack instr[31:0] internal cycles iab iab+4 iab+8
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-23 figure c-6 debug state entry clk inmreq iseq ia[31:1] dbgack instr[31:0] memory cycles 12 3 internal cycles dbgiebkpt
debug in depth c-24 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.8 behavior of the program counter during debug the debugger must keep track of what happens to the pc, so that you can force the arm9e-s to branch back to the place at which program flow was interrupted by debug. program flow can be interrupted by any of the following: ? a breakpoint ? a watchpoint ? a watchpoint when another exception occurs ? a debug request ? a system speed access. c.8.1 breakpoints entry to debug state from a breakpointed instruction advances the pc by 16 bytes in arm state, or 8 bytes in thumb state. each instruction executed in debug state advances the pc by one address (4 bytes). the normal way to exit from debug state after a breakpoint is to remove the breakpoint and branch back to the previously breakpointed address. for example, if the arm9e-s entered debug state from a breakpoint set on a given address and two debug speed instructions were executed, a branch of seven addresses must occur (four for debug entry, plus two for the instructions, plus one for the final branch). the following sequence shows arm instructions scanned into scan chain 1. this is the most significant bit (msb) first, so the first digit represents the value to be scanned into the sysspeed bit, followed by the instruction. 0 eafffff9 ; b -7 addresses (twos complement) 1 e1a00000 ; nop (mov r0, r0), sysspeed bit is set after the arm9e-s enters debug state, it must execute a minimum of two instructions before the branch, although these can both be nops ( mov r0, r0 ). for small branches, you can replace the final branch with a subtract, with the pc as the destination ( sub pc, pc, #28 in the above example). c.8.2 watchpoints to return to program execution after entry to debug state from a watchpoint, use the same procedure described in breakpoints . debug entry adds four addresses to the pc, and every instruction adds one address. the difference from breakpoint is that the instruction that caused the watchpoint has executed, and the program must return to the next instruction.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-25 c.8.3 watchpoint with another exception if a watchpointed access also has a data abort returned, the arm9e-s enters debug state in abort mode. entry into debug is held off until the core changes into abort mode, and has fetched the instruction from the abort vector. a similar sequence follows when an interrupt, or any other exception, occurs during a watchpointed memory access. the arm9e-s enters debug state in the mode of the exception. the debugger must check to see if an exception has occurred by examining the current and previous mode (in the cpsr and spsr), and the value of the pc. when an exception has taken place, you must be given the choice of servicing the exception before debugging. for example, suppose that an abort has occurred on a watchpointed access and ten instructions have been executed in debug state. you can use the following sequence to return to program execution: 0 eafffff1 ; b -15 addresses (twos complement) 1 e1a00000; nop (mov r0, r0), sysspeed bit is set this code forces a branch back to the abort vector, causing the instruction at that location to be refetched and executed. note after the abort service routine, the instruction that caused the abort and watchpoint is refetched and executed. this triggers the watchpoint again, and the arm9e-s reenters debug state. c.8.4 watchpoint and breakpoint it is possible to have a watchpoint and breakpoint condition occurring simultaneously. this can happen when an instruction causes a watchpoint, and the following instruction has been breakpointed. you must perform the same calculation as for breakpoints on page c-24 to determine where to resume. in this case, it is at the breakpoint instruction, because this has not been executed.
debug in depth c-26 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.8.5 debug request entry into debug state through a debug request is similar to a breakpoint. entry to debug state adds four addresses to the pc, and every instruction executed in debug state adds one address. for example, the following sequence handles a situation in which the user has invoked a debug request, and then decides to return to program execution immediately: 0 eafffffb ; b -5 addresses (2s complement) 1 e1a00000; nop (mov r0, r0), sysspeed bit is set this code restores the pc, and restarts the program from the next instruction. c.8.6 system speed access when a system speed access is performed during debug state, the value of the pc increases by five addresses. system speed instructions access the memory system, and so it is possible for aborts to take place. if an abort occurs during a system speed memory access, the arm9e-s enters abort mode before returning to debug state. this scenario is similar to an aborted watchpoint, but the problem is much harder to fix because the abort is not caused by an instruction in the main program, and so the pc does not point to the instruction that caused the abort. an abort handler usually looks at the pc to determine the instruction that caused the abort, and the abort address. in this case, the value of the pc is invalid, but because the debugger can determine which location was being accessed, you can write the debugger to help the abort handler fix the memory system. c.8.7 summary of return address calculations the calculation of the branch return address can be summarized as: -(4+n+5s) where n is the number of debug speed instructions executed (including the final branch), and s is the number of system speed instructions executed.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-27 c.9 priorities and exceptions when a breakpoint or a debug request occurs, the normal flow of the program is interrupted. therefore you can treat debug as another type of exception. the interaction of the debugger with other exceptions is described in behavior of the program counter during debug on page c-24. this section covers the priorities. c.9.1 breakpoint with prefetch abort when a breakpointed instruction fetch causes a prefetch abort, the abort is taken and the breakpoint is disregarded. normally, prefetch aborts occur when, for example, an access is made to a virtual address that does not physically exist, and the returned data is therefore invalid. in such a case, the normal action of the operating system is to swap in the page of memory, and to return to the previously invalid address. this time, when the instruction is fetched, and providing the breakpoint is activated (it might be data-dependent), the arm9e-s enters debug state. the prefetch abort, therefore, takes higher priority than the breakpoint. c.9.2 interrupts when the arm9e-s enters debug state, interrupts are automatically disabled. if an interrupt is pending during the instruction prior to entering debug state, the arm9e-s enters debug state in the mode of the interrupt. on entry to debug state, the debugger cannot assume that the arm9e-s is in the mode expected by your program. the arm9e-s must check the pc, the cpsr, and the spsr to determine accurately the reason for the exception. debug, therefore, takes higher priority than the interrupt, but the arm9e-s does recognize that an interrupt has occurred. c.9.3 data aborts when a data abort occurs on a watchpointed access, the arm9e-s enters debug state in abort mode. the watchpoint, therefore, has higher priority than the abort, but the arm9e-s remembers that the abort happened.
debug in depth c-28 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.10 embeddedice-rt logic the embeddedice-rt logic is integral to the arm9e-s processor core. it has two hardware breakpoint or watchpoint units, each of which can be configured to monitor either the instruction memory interface or the data memory interface. each watchpoint unit has registers that set the address, data, and control fields for both values and masks. the registers used are shown in table c-4. because the arm9e-s processor core has a harvard architecture, you must specify whether the watchpoint unit examines the instruction or the data interface. this is specified by bit 3 of the control value register: ? when bit 3 is set, the data interface is examined ? when bit 3 is clear, the instruction interface is examined. there cannot be a dont care case for this bit because the comparators cannot compare the values on both buses simultaneously. therefore, bit 3 of the control mask register is always clear and cannot be programmed high. bit 3 also determines whether the internal ibreakpt or dwpt signal must be driven by the result of the comparison. figure c-7 on page c-30 gives an overview of the operation of the embeddedice-rt logic. the arm9e-s embeddedice-rt logic has dedicated hardware that allows single-stepping through code. this reduces the work required by an external debugger, and removes the need to flush the instruction cache. there is also hardware to allow efficient trapping of accesses to the exception vectors. these blocks of logic free the two general-purpose hardware breakpoint or watchpoint units for use by the programmer at all times. the general arrangement of the embeddedice-rt logic is shown in figure c-7 on page c-30. c.10.1 register map the embeddedice-rt logic register map is shown in table c-4. table c-4 arm9e-s embeddedice-rt logic register map address width function type 00000 6 debug control read/write 00001 5 debug status read-only 00010 8 vector catch control read/write 00100 6 debug comms control read-only a
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-29 c.10.2 programming and reading embeddedice-rt logic registers an embeddedice-rt logic register is programmed by shifting data into the embeddedice scan chain (scan chain 2). the scan chain is a 38-bit register comprising: ? a 32-bit data field ? a 5-bit address field ? a read/write bit. this is shown in figure c-7 on page c-30. 00101 32 debug comms data read/write 01000 32 watchpoint 0 address value read/write 01001 32 watchpoint 0 address mask read/write 01010 32 watchpoint 0 data value read/write 01011 32 watchpoint 0 data mask read/write 01100 9 watchpoint 0 control value read/write 01101 8 watchpoint 0 control mask read/write 10000 32 watchpoint 1 address value read/write 10001 32 watchpoint 1 address mask read/write 10010 32 watchpoint 1 data value read/write 10011 32 watchpoint 1 data mask read/write 10100 9 watchpoint 1 control value read/write 10101 8 watchpoint 1 control mask read/write a. an attempted write to the comms channel control register can be used to reset bit 0 of that register. table c-4 arm9e-s embeddedice-rt logic register map (continued) address width function type
debug in depth c-30 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b figure c-7 arm9e-s embeddedice macrocell overview if a watchpoint is requested on a particular memory location but the data value is irrelevant, you can program the data mask register to 0xffff ffff (all bits set to 1), so that the entire data bus value is masked. c.10.3 using the mask registers for each value register there is an associated mask register in the same format. setting a bit to 1 in the mask register causes the corresponding bit in the value register to be ignored in any comparison. address data r/w 0 31 0 4 scan chain register value mask comparator rangeout address decoder ia[31:1] da[31:0] tdo tdi update 32 registers enable 5 breakpoint/ watchpoint address data control address data control address data control i control d control instr[31:0] dd[31:0]
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-31 c.10.4 watchpoint control registers the format of the control registers depends on how bit 3 is programmed. if bit 3 of the control register is programmed to a 1, the breakpoint comparators examine the data address, data, and control signals. in this case, the format of the control register is as shown in figure c-8. note you cannot mask bit 8 and bit 3. figure c-8 watchpoint control register for data comparison data comparison bit functions are described in table c-5. 76543210 enable range chain dbgext dntrans 1 dmas[1] dnrw dmas[0] 8 table c-5 watchpoint control register for data comparison functions bit number name function 0 dnrw compares against the data not read/write signal from the core in order to detect the direction of the data data bus activity. dnrw is 0 for a read, and 1 for a write. 2:1 dmas[1:0] compares against the dmas[1:0] signal from the core in order to detect the size of the data data bus activity. 4 dntrans compares against the data not translate signal from the core in order to determine between a user mode ( dntrans = 0) data transfer, and a privileged mode ( dntrans = 1) transfer. 5 dbgext is an external input into the embeddedice-rt logic that allows the watchpoint to be dependent upon some external condition. the dbgext input for watchpoint 0 is labeled dbgext[0] , and the dbgext input for watchpoint 1 is labeled dbgext[1] .
debug in depth c-32 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b if bit 3 of the control register is programmed to 0, the comparators examine the instruction address, instruction data, and instruction control buses. in this case bits [2] and [0] of the mask register must be set to dont care (programmed to 1_1). the format of the register in this case is as shown in figure c-9. figure c-9 watchpoint control register for instruction comparison 6 chain selects the chain output of another watchpoint unit in order to implement some debugger requests. for example, breakpoint on address yyy only when in process xxx . in the arm9e-s embeddedice-rt logic, the chainout output of watchpoint 1 is connected to the chain input of watchpoint 0. the chainout output is derived from a latch. the address or control field comparator drives the write enable for the latch and the input to the latch is the value of the data field comparator. the chainout latch is cleared when the control value register is written or when dbgntrst is low. 7 range can be connected to the range output of another watchpoint register. in the arm9e-s embeddedice-rt logic, the address comparator output of watchpoint 1 is connected to the range input of watchpoint 0. this allows you to couple two watchpoints for detecting conditions that occur simultaneously, for example, for range-checking. 8 enable if a watchpoint match occurs, the internal dwpt signal is only asserted when the enable bit is set. this bit only exists in the value register. it cannot be masked. table c-5 watchpoint control register for data comparison functions (continued) bit number name function 76543210 enable range chain dbgext intrans 0 x x itbit 8
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-33 instruction comparison bit functions are described in table c-6. . table c-6 watchpoint control register for instruction comparison functions bit number name function 1 itbit compares against the thumb state signal from the core to determine between a thumb ( itbit = 1) instruction fetch or an arm ( itbit = 0) instruction fetch. 4 intrans compares against the not translate signal from the core in order to determine between a user mode ( intrans = 0) instruction fetch, and a privileged mode ( intrans = 1) fetch. 5 dbgext is an external input into the embeddedice-rt logic that allows the watchpoint to be dependent upon some external condition. the dbgext input for watchpoint 0 is labelled dbgext[0] , and the dbgext input for watchpoint 1 is labeled dbgext[1] . 6 chain selects the chain output of another watchpoint unit in order to implement some debugger requests. for example, breakpoint on address yyy only when in process xxx . in the arm9e-s embeddedice-rt logic, the chainout output of watchpoint 1 is connected to the chain input of watchpoint 0. the chainout output is derived from a latch. the address or control field comparator drives the write enable for the latch, and the input to the latch is the value of the data field comparator. the chainout latch is cleared when the control value register is written, or when ntrst is low. 7 range can be connected to the range output of another watchpoint register. in the arm9e-s embeddedice-rt logic, the address comparator output of watchpoint 1 is connected to the range input of watchpoint 0. this allows you to couple two watchpoints for detecting conditions that occur simultaneously, for example, for range-checking. 8 enable if a watchpoint match occurs, the internal ibreakpt signal is only asserted when the enable bit is set. this bit only exists in the value register, it cannot be masked.
debug in depth c-34 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.10.5 debug control register the debug control register is 6 bits wide. writing control bits occurs during a register write access (with the read/write bit high). reading control bits occurs during a register read access (with the read/write bit low). figure c-10 shows the function of each bit in this register. figure c-10 debug control register format these functions are described in table c-7 and table c-8 on page c-35. 543210 embedded-ice disable monitor mode enable single-step intdis dbgrq dbgack table c-7 debug control register bit functions bit number name function 5embedded- ice disable controls the address and data comparison logic contained within the embedded-ice logic. when set to 1, the address and data comparators are disabled. when set to 0, the address and data comparators are enabled. you can use this bit to save power in a system where the embedded-ice functionality is not required. the reset state of this bit is 0 (comparators enabled). an extra piece of logic initialized by debug reset ensures that the embedded-ice logic is automatically disabled out of reset. this extra logic is set by debug reset and is automatically reset on the first access to scan chain 2. 4monitor mode enable controls the selection between monitor mode debug (monitor mode enable = 1) and halt mode debug. in monitor mode, breakpoints and watchpoints cause prefetch aborts and data aborts to be taken (respectively). at reset, the monitor mode enable bit is set to 1. 3 single-step controls the single-step hardware. this is explained in more detail in single-stepping on page c-40. 2 intdis if bit 2 ( intdis ) is asserted, the interrupt signals to the processor are inhibited. table c-8 shows interrupt signal control. 1:0 dbgrq, dbgack these bits allow the values on dbgrq and dbgack to be forced.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-35 both irq and fiq are disabled when the processor is in debug state (dbgack =1), or when intdis is forced. as shown in figure c-12 on page c-37, the value stored in bit 1 of the control register is synchronized and then ored with the external edbgrq before being applied to the processor. in the case of dbgack , the value of dbgack from the core is ored with the value held in bit 0 to generate the external value of dbgack seen at the periphery of the arm9e-s. this allows the debug system to signal to the rest of the system that the core is still being debugged even when system-speed accesses are being performed (in which case the internal dbgack signal from the core is low). the structure of the debug control and status registers is shown in figure c-12 on page c-37. c.10.6 debug status register the debug status register is five bits wide. if it is accessed for a read (with the read/write bit low), the status bits are read. the format of the debug status register is shown in figure c-11. figure c-11 debug status register table c-8 interrupt signal control dbgack intdis interrupts 0 0 permitted 1 x inhibited x 1 inhibited 76543210 8 itbit syscomp ifen dbgrq dbgack 432 1 0
debug in depth c-36 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b the function of each bit in this register is shown in table c-9. the structure of the debug control and status registers is shown in figure c-12 on page c-37. table c-9 debug status register bit functions bit number name function 1:0 dbgrq, dbgack allow the values on the synchronized versions of edbgrq and dbgack to be read. 2 ifen allows the state of the core interrupt enable signal to be read. 3 syscomp allows the state of the syscomp bit from the core to be read. this allows the debugger to determine that a memory access from the debug state has completed. 4 itbit allows the status of the output itbit to be read. this enables the debugger to determine what state the processor is in, and therefore which instructions to execute.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-37 figure c-12 debug control and status register structure dbgack (from core) bit 2 intdis bit 1 dbgrq + + + bit 2 ifen bit 1 dbgrq bit 0 dbgack bit 0 dbgack + bit 3 syscomp bit 4 itbit edbgrq (from arm9e-s input) dbgack (from core) syscomp (from core) itbit (from core) dbgack (to arm9e-s output) dbgrq (to core) interrupt mask enable (to core) debug status register debug control register
debug in depth c-38 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.10.7 vector catch register the arm9e-s embeddedice-rt logic controls hardware to enable accesses to the exception vectors to be trapped in an efficient manner. this is controlled by the vector catch register, as shown in figure c-13. the functionality is described in vector catching on page c-39. figure c-13 vector catch register 76543210 fiq irq reserved d_abort p_abort swi undef reset
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-39 c.11 vector catching the arm9e-s embeddedice-rt logic contains hardware that allows efficient trapping of fetches from the vectors during exceptions. this is controlled by the vector catch register. if one of the bits in this register is set high and the corresponding exception occurs, the processor enters debug state as if a breakpoint has been set on an instruction fetch from the relevant exception vector. for example, if the processor executes a swi instruction while bit 2 of the vector catch register is set, the arm9e-s fetches an instruction from location 0x8 . the vector catch hardware detects this access and forces the internal ibreakpt signal high into the arm9e-s control logic. this, in turn, forces the arm9e-s to enter debug state. the behavior of the hardware is independent of the watchpoint comparators, leaving them free for general use. the vector catch register is sensitive only to fetches from the vectors during exception entry. therefore, if code branches to an address within the vectors during normal operation, and the corresponding bit in the vector catch register is set, the processor is not forced to enter debug state. in monitor mode debug, vector catching is disabled on data aborts and prefetch aborts to avoid the processor being forced into an unrecoverable state as a result of the aborts that are generated for the monitor mode debug.
debug in depth c-40 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.12 single-stepping the arm9e-s embeddedice-rt logic contains logic that allows efficient single-stepping through code. this leaves the watchpoint comparators free for general use. enable this function by setting bit 3 of the debug control register. the state of this bit must only be altered while the processor is in debug state. if the processor exits debug state and this bit is high, the processor fetches an instruction, executes it, and then immediately reenters debug state. this happens independently of the watchpoint comparators. if a system speed data access is performed while in debug state, the debugger must ensure that the control bit is clear first. note this bit must not be set when using monitor mode debug.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-41 c.13 coupling breakpoints and watchpoints you can couple watchpoint units 1 and 0 together using the chain and range inputs. using chain enables watchpoint 0 to be triggered only if watchpoint 1 has previously matched. using range enables you to perform simple range checking by combining the outputs of both watchpoints. c.13.1 breakpoint and watchpoint coupling example let: av[31:0] be the value in the address value register am[31:0] be the value in the address mask register a[31:0] be the ia bus from the arm9e-s if control register bit 3 is clear, or the da bus from the arm9e-s if control register bit 3 is set dv[31:0] be the value in the data value register dm[31:0] be the value in the data mask register d[31:0] be the instr bus from the arm9e-s if control register bit 3 is clear, or the rdata bus from the arm9e-s if control register bit 3 is set and the processor is doing a read, or the wdata bus from the arm9e-s if control register bit 3 is set and the processor is doing a write cv[8:0] be the value in the control value register cm[7:0] be the value in the control mask register c[9:0] be the combined control bus from the arm9e-s, other watchpoint registers, and the dbgext signal. chainout signal the chainout signal is derived as follows: when (({av[31:0],cv[4,2:0]} xnor {a[31:0],c[4,2:0]}) or {am[31:0],cm[4:0]} == 0xfffffffff) chainout = ((({dv[31:0],cv[6:4]} xnor {d[31:0],c[7:5]}) or {dm[31:0],cm[7:5]}) == 0x7ffffffff) the chainout output of watchpoint register 1 provides the chain input to watchpoint 0. this chain input allows for quite complicated configurations of breakpoints and watchpoints. note there is no chain input to watchpoint 1 and no chain output from watchpoint 0.
debug in depth c-42 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b take, for example, the request by a debugger to breakpoint on the instruction at location yyy when running process xxx in a multiprocess system. if the current process id is stored in memory, you can implement the above function with a watchpoint and breakpoint chained together. the watchpoint address points to a known memory location containing the current process id, the watchpoint data points to the required process id, and the enable bit is set to off. the address comparator output of the watchpoint is used to drive the write enable for the chainout latch. the input to the latch is the output of the data comparator from the same watchpoint. the output of the latch drives the chain input of the breakpoint comparator. the address yyy is stored in the breakpoint register, and when the chain input is asserted, the breakpoint address matches, and the breakpoint triggers correctly. c.13.2 dbgrng signal the dbgrng signal is derived as follows: dbgrng = ((({av[31:0],cv[4,2:0]} xnor {a[31:0],c[4,2:0]}) or {am[31:0],cm[4:0]}) == 0xfffffffff) and ((({dv[31:0],cv[7:5]} xnor {d[31:0],c[7:5]}) or dm[31:0],cm[7:5]}) == 0x7ffffffff) the range input to watchpoint unit 0 is derived as the address comparison of watchpoint unit 1, that is: rangein = ((av[31:0] xnor a[31:0]) or am[31:0] == 0xffff ffff) this range input allows you to couple two breakpoints together to form range breakpoints. selectable ranges are restricted to being powers of 2. for example, if a breakpoint is to occur when the address is in the first 256 bytes of memory, but not in the first 32 bytes, program the watchpoint registers as follows: for watchpoint 1: 1. program watchpoint 1 with an address value of 0x00000000 and an address mask of 0x0000001f . 2. clear the enable bit. 3. program all other watchpoint 1 registers as normal for a breakpoint. an address within the first 32 bytes causes the range output to go high because the address matches, but does not trigger the breakpoint because the enable is low.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-43 for watchpoint 0: 1. program watchpoint 0 with an address value of 0x00000000 and an address mask of 0x000000ff . 2. set the enable bit. 3. program the range bit to match a 0. 4. program all other watchpoint 0 registers as normal for a breakpoint. if watchpoint 0 matches but watchpoint 1 does not (that is the range input to watchpoint 0 is 0), the breakpoint is triggered.
debug in depth c-44 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b c.14 disabling embeddedice-rt you can disable embeddedice-rt by wiring the dbgen input low. when dbgen is low: ? dbgiebkpt , dbgdewpt , and dbgrq are forced low to the core. (dbgrq is the internal dbgrq, which is a combination of the external input edbgrq and the debug control register bit 1 dbgrq.) ? dbgack is forced low from the arm9e-s. ? interrupts pass through to the processor uninhibited.
debug in depth arm ddi 0165b copyright ? 2000 arm limited. all rights reserved. c-45 c.15 embeddedice-rt timing embeddedice-rt samples the dbgext[1] and dbgext[0] inputs on the rising edge of clk . refer to chapter 9 ac parameters for details of the required setup and hold times for these signals.
debug in depth c-46 copyright ? 2000 arm limited. all rights reserved. arm ddi 0165b
copyright ? 2000 arm limited. all rights reserved. index-i index the items in this index are listed in alphabetic order. the references given are to page numbers. a abort 2-23 data 2-23, c-27 handler 2-24 mode 2-8 prefetch 2-23, c-27 vector c-25 aborted watchpoint c-26 access system speed c-24 watchpointed c-25, c-27 address bits, significant 4-7 addressing mode 2 1-16 addressing mode 2 (privileged) 1-17 addressing mode 3 1-18 addressing mode 4 (load) 1-18 addressing mode 4 (store) 1-18 alignment 2-7 arm instruction set 1-5 instruction set summary 1-12 state 1-5, 2-3 arm state to thumb state 2-3 arm9e-s architecture 1-5 block diagram 1-7 core diagram 1-7 functional diagram 1-7 instruction set 1-10 signals compared to arm9tdmi b-2 b banked registers 2-9, c-19 big-endian 2-4 bkpt 2-25 block diagram, arm9e-s 1-7 boundary-scan chain cells c-5 interface c-5 breakpoint instruction 2-25 breakpoints 7-7, 7-9, c-24 instruction boundary 7-10 prefetch abort 7-10 burst types 4-10 bus cycles, clken 4-31 busy-wait 6-6, 6-17 abandoned 6-17 interrupted 6-17 bypass register c-9, c-10 byte 2-7 access 4-21 c c flag 2-16 cfgbigend a-6 cfgdisltbit a-6
index index-ii copyright ? 2000 arm limited. all rights reserved. cfghivecs a-6 chain c-42 chsd a-7 chse a-7 clk a-2 clken a-2 clock domains 7-14 maximum skew 9-8 system 7-14 test 7-14 code density 1-5 cold reset 3-3 compression, instruction 1-5 condition code flags 2-16 configuration input timing 9-4 control bits 2-17 coprocessor expansion interface signals b-2 handshake signals 6-6 interface 6-2 mcr 6-18 register transfer cycle 4-29 register transfer instructions 7-16 coprocessor instructions busy-wait 6-6 during busy-wait 6-17 during interrupts 6-17 privileged instructions 6-16 privileged modes 6-16 core diagram, arm9e-s 1-7 coreclkenin a-2 coreclkenout a-2 cpsr 2-9, 2-12, 2-14, 2-16 mode c-25 cpu reset 3-4 current program status register 2-9, 2-12, 2-14, 2-16 cycle internal 4-9, 4-11 merged i-s 4-11 nonsequential 4-9 sequential 4-9 d da a-4 dabort a-4 data abort 2-23, c-27 dependencies 1-4 interface 4-13 memory interface timing 9-3 types 2-7 dbgack a-9 dbgcommrx a-9 dbgcommtx a-9 dbgdewpt a-4 dbgen a-9 dbgext a-9 dbgiebkpt a-3 dbginstrexec a-9 dbginstrvalid a-9 dbgir a-8 dbgntdoen a-8 dbgntrst 3-2, a-8 dbgrng a-9 dbgrqi a-9 dbgscreg a-8 dbgsdin a-8 dbgtapsm a-8 dbgtcken a-8 dbgtdi a-8 dbgtdo a-8 dbgtms a-8 debug comms control register 7-16 comms data read register 7-16 comms data write register 7-16 control register 7-6 entry from arm state c-18 entry from thumb state c-18 expansion signals b-6 extensions 7-2 hardware extensions 7-4 interface 7-2 interface signals 7-5 multi-ice 7-14 request c-24 state 7-5 state, processor restart on exit c-9 status register 7-6 support 7-6 decode 1-2 determining core state 7-15 system state 7-15 device identification code c-9, c-10 device reset 3-2 disabling embeddedice-rt 7-8 dlock a-4 dmas a-4 dmore a-4 dnm a-5 dnmreq a-4 dnrw a-5 dntrans a-5 dseq a-5 e edbgrq a-9 embeddedice-rt c-28 debug status register 7-15 disabling 7-8 functionality c-28 hardware c-28 logic 7-4, 7-6 operation 7-6 overview 7-6 programming c-2 register map c-28 registers, accessing c-3 reset 3-4 single stepping c-40 endian effects 4-7, 4-30 endianness 2-4 exception entry and exit 2-20 entry, arm state 2-21 entry, thumb state 2-21 priority 2-27 vectors 2-26 exceptions 2-20 fiq 2-22 irq 2-22 execute 1-2 f f bit, fiq disable 2-17 fetch 1-2 fiq disable, f bit 2-17 exception 2-22 mode 2-8 flags 2-16 forwarding 1-4 functional diagram, arm9e-s 1-7 h halfword 2-7 halfword access 4-21 high registers 2-15 i i bit, irq disable 2-17 ia a-3 iabort a-3 id register c-5, c-9, c-10 idcode instruction c-5, c-11 identification register see id register inm a-3
index copyright ? 2000 arm limited. all rights reserved. index-iii inmreq a-3 instr a-3 instruction compression 1-5 coprocessor register transfer 7-16 fetch, nonsequential 4-9 fetch, sequential 4-10 interface 4-3 interface cycle types 4-8 length 2-6 pipeline 1-2 pipeline operation 1-4 register c-9, c-10 scan_n c-8, c-12 system speed c-26 instruction set arm 1-5, 1-12 summary 1-10 thumb 1-5 interface boundary-scan c-5 debug 7-2 interlocking 1-4 internal cycle 4-9, 4-11 interrupts disable flags 2-21 interworking 2-3 intest instruction c-12 mode c-16 intrans a-3 irq disable, i bit 2-17 exception 2-22 mode 2-8 iseq a-3 itbit a-3 j jtag instructions idcode c-5, c-11 intest c-12 restart c-9 scan_n c-12, c-16 scan_n tap c-14 tap c-11 jtag interface 7-4, 7-5 l latecancel a-7 link register 2-9, 2-12, 2-14 little-endian 2-4 low registers 2-15 lr 2-12, 2-14 m mcr 6-18 memory 1-2 access 1-4 cycle 4-8 formats 2-4 interface 4-2 requests, withdrawal of 4-32 merged i-s cycle 4-11 mode abort 2-8, c-25 bits 2-18 fiq 2-8 identifier 2-10 irq 2-8 operating 2-8 privileged 2-8 psr bit values 2-18 supervisor 2-8 system 2-8 undefined 2-8 user 2-8 multi-ice 7-14 n n flag 2-16 nfiq a-6 nirq a-6 nonsequential cycle 4-9 nreset 3-2, a-6 o operating modes 2-8 operating state arm 2-3 t bit 2-18 thumb 2-3 p pass a-7 pc 2-12, 2-14 pipeline arm 6-2 coprocessor 6-2 pipeline follower 6-2 power-on reset 3-3 prefetch abort 2-23, c-27 priority of exceptions 2-27 privileged modes 2-8 processor state, determining c-18 program counter 2-9, 2-12, 2-14 program status registers 2-16 psr control bits 2-17 mode bit values 2-18 reserved bits 2-19 q q flag 2-17 r rdata a-4 register banked 2-9 current program status 2-9 general-purpose 2-9 high 2-15 link 2-9 program status 2-16 saved program status 2-9 status 2-9 register, debug bypass c-10 comms control 7-16 comms data read 7-16 comms data write 7-16 control 7-6 embeddedice-rt debug status 7-15 embeddedice-rt, accessing c-3 id c-5, c-10 instruction c-9, c-10 scan path select c-8, c-10 status 7-6 test data c-10 reserved bits, psr 2-19 reset 2-22, 3-2 behavior 3-5 cpu 3-4 embeddedice-rt 3-4 modes 3-3 power-on 3-3 warm 3-4 restart instruction c-9 restart on exit from debug c-9 s saved program status register 2-9 scan cells c-14 path c-2 path select register c-8, c-10 scan chains number allocation c-12 scan chain 1 c-2, c-10, c-14 scan chain 2 c-2, c-10, c-16 scanenable b-5 scanin b-5
index index-iv copyright ? 2000 arm limited. all rights reserved. scanout b-5 scan_n c-8, c-12, c-16 sequential cycle 4-9 serial interface, jtag 7-4, 7-5 signal types address class 4-4, 4-15 data timed 4-6, 4-18 debug interface 7-5 signals cfgbigend a-6 cfgdisltbit a-6 cfghivecs a-6 chain c-42 chsd a-7 chse a-7 clk a-2 clken a-2 coreclkenin a-2 coreclkenout a-2 da a-4 dabort a-4 dbgack a-9 dbgcommrx a-9 dbgcommtx a-9 dbgdewpt a-4 dbgen a-9 dbgext a-9 dbgiebkpt a-3 dbginstrexec a-9 dbginstrvalid a-9 dbgir a-8 dbgntdoen a-8 dbgntrst 3-2, a-8 dbgrng a-9 dbgrqi a-9 dbgscreg a-8 dbgsdin a-8 dbgsdout a-8 dbgtapsm a-8 dbgtcken a-8 dbgtdi a-8 dbgtdo a-8 dbgtms a-8 dlock a-4 dmas a-4 dmore a-4 dnm a-5 dnmreq a-4 dnrw a-5 dntrans a-5 dseq a-5 edbgrq a-9 ia a-3 iabort a-3 inm a-3 inmreq a-3 instr a-3 intrans a-3 iseq a-3 itbit a-3 latecancel a-7 nfiq a-6 signals (continued) nirq a-6 nreset 3-2, a-6 pass a-7 rdata a-4 scanenable b-5 scanin b-5 scanout b-5 tapid a-9 wdata a-4 significant address bits 4-7 single-step core operation c-8 single-stepping c-40 software interrupt 2-24 sp 2-12, 2-14 spsr 2-9, 2-12, 2-14, 2-16, c-25 stack pointer 2-12, 2-14 state arm 1-5 debug 7-5 thumb 1-5 states core c-18 system c-18 tap c-14 tap controller 7-2 state, switching 2-3 status registers 2-9 sticky overflow flag 2-17 stored program status register 2-12, 2-14, 2-16 supervisor mode 2-8 swi 2-24 switching states 2-3 system mode 2-8 system speed instruction c-26 system state, determining 7-15 t t bit 2-18 tap 7-2 controller 7-4, c-2, c-3, c-14 controller, states 7-2 instruction c-11 state c-14 tapid a-9 test access port 7-2 test clock 7-14 test data registers c-10 thumb instruction set 1-5 state 1-5, 2-3, 2-12 thumb state to arm state 2-3 timing configuration input 9-4 data memory interface 9-3 exception input 9-4 u undefined instruction 2-25 undefined mode 2-8 unused instruction codes c-9 user mode 2-8 v v flag 2-16 vector, exception 2-26 w warm reset 3-4 watchpointed access c-25, c-27 memory access c-25 watchpoints 7-6, 7-7, c-24 aborted c-26 timing 7-11 with exception c-24 wdata a-4 word 2-7 writeback 1-2 z z flag 2-16

▲Up To Search▲

Price & Availability of ATMEGA64-16AL

	To Download ATMEGA64-16AL Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .